xfs
[Top] [All Lists]

Re: [PATCH 02/17] xfs: skip writeback from reclaim context

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 02/17] xfs: skip writeback from reclaim context
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 3 Jun 2010 09:02:09 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20100602100812.GA25035@xxxxxxxxxxxxx>
References: <20100531160727.842750532@xxxxxxxxxxxxxxxxxxxxxx> <20100531160859.184576507@xxxxxxxxxxxxxxxxxxxxxx> <20100602043957.GB7011@dastard> <20100602100812.GA25035@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Jun 02, 2010 at 06:08:12AM -0400, Christoph Hellwig wrote:
> On Wed, Jun 02, 2010 at 02:39:57PM +1000, Dave Chinner wrote:
> > Also worth thinking about is if should be checked in
> > xfs_vm_releasepage() as well to avoid the same stack issues if it
> > triggers allocation...
> 
> I agree this is a potential problem as well.
> 
> I did some QA runs with this thrown in, and it causes massive OOM killer
> wreckage in xfstests.  I've also cross-checked btrfs and ext4 and
> neither one skips ->releasepage from reclaim context.

Did you skip it unconditionally, or only when a transaction was
required?

The scary part is that I've seen stack traces (i.e. most stack used)
through this reclaim path for delalloc conversion even for
allocations that are GFP_NOFS and the only thing saving us from
deadlocks is th PF_FSTRANS check. Even worse is that
shrinker_page_list() will call try_to_release_pages() without
checking whether it's allowed to enter the filesystem or not, so we
can be doing block allocation in places we've specifically told the
memory allocation subsystem not to....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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