[Top] [All Lists]

Re: 3.14-rc2 XFS backtrace because irqs_disabled.

To: Dave Chinner <david@xxxxxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx>
Subject: Re: 3.14-rc2 XFS backtrace because irqs_disabled.
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 15 Feb 2014 15:50:29 -0800
Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx>, Dave Jones <davej@xxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AdJLRTFoFMwzL6BkG37RrqmmQW0QVPuip8kTfAwqdwo=; b=mLYwDn5GminEiWKWCJPAhrAbLsSRqJKuU/F1aRd5idvX7ayIK0UImqHM08E7NF5TqV /AOKGjZb7auKk5+AZskbDXJJBXoI3rvEnhOJWa46zSGPyECfCQAm2gXUIHWun206VcRX faEd9GiZcj5Q7FGXIwf9U69X4Rv2ScS4BJWZdrpR+GKkh/FwCnF6+N5Gm3qXhPtrco00 reWKuTMa7kz3GiX01/hBFzRPC9q6jHu8x4SzJF6XymC1CzbHHihZJl4mvzgXF5Ha0E3Z prCEZw4hCckdfy0oKR80thMs9LhOOSEkEUctLKUnALKSYwkMfDepEhxDdSplz0zWx/Gg qyAg==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AdJLRTFoFMwzL6BkG37RrqmmQW0QVPuip8kTfAwqdwo=; b=CsN0/RBYKmV9oICPhe2dexEVTWhvC/Qg2jwKQRBKtSl91vjVexoCqGWYgBa3FQGg+V 51X/buK2pHo3z/M5mCb8UCMG0qJjjC+wzTQrpKfukBT81xmlSJV0MVDYPNl8zjlPKDs0 +HhDAM384Z/dxfQDLBNSYpO265W3VN92BX8yw=
In-reply-to: <20140214002427.GN13997@dastard>
References: <20140211210841.GM13647@dastard> <52FA9ADA.9040803@xxxxxxxxxxx> <20140212004403.GA17129@xxxxxxxxxx> <20140212010941.GM18016@xxxxxxxxxxxxxxxxxx> <CA+55aFwoWT-0A_KTkXMkNqOy8hc=YmouTMBgWUD_z+8qYPphjA@xxxxxxxxxxxxxx> <20140212040358.GA25327@xxxxxxxxxx> <20140212042215.GN18016@xxxxxxxxxxxxxxxxxx> <20140212054043.GB13997@dastard> <CA+55aFxy2t7bnCUc-DhhxYxsZ0+GwL9GuQXRYtE_VzqZusmB9A@xxxxxxxxxxxxxx> <20140212071829.GE13997@dastard> <20140214002427.GN13997@dastard>
Sender: linus971@xxxxxxxxx
[ Added linux-mm to the participants list ]

On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?

Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
people, your parents were some seriously boring people, were they not?
We've got too many Dave's around), but DaveC earlier pointed out that
pretty much any memory allocation path can end up using 3kB of stack
even without XFS being involved.

Which does bring up the question whether we should look (once more) at
the VM direct-reclaim path, and try to avoid GFP_FS/IO direct

Direct reclaim historically used to be an important throttling
mechanism, and I used to not be a fan of trying to avoid direct
reclaim. But the stack depth issue really looks to be pretty bad, and
I think we've gotten better at throttling explicitly, so..

I *think* we already limit filesystem writeback to just kswapd (in
shrink_page_list()), but DaveC posted a backtrace that goes through
do_try_to_free_pages() to shrink_slab(), and through there to the
filesystem and then IO. That looked like a disaster.

And that's because (if I read things right) shrink_page_list() limits
filesystem page writeback to kswapd, but not swap pages. Which I think
probably made more sense back in the days than it does now (I
certainly *hope* that swapping is less important today than it was,
say, ten years ago)

So I'm wondering whether we should remove that page_is_file_cache()
check from shrink_page_list()?

And then there is that whole shrink_slab() case...


<Prev in Thread] Current Thread [Next in Thread>