Re: xfsdump stuck in io_schedule

[Christoph Hellwig <hch@xxxxxxxxxxxxx>]

On Sun, Nov 17, 2002 at 12:10:51PM -0800, Andrew Morton wrote:
> That's an atomic, low-priority allocation.  It is expected to
> fail, and can easily do so.
> 
> So there's your reason - this can quite easily outrun kswapd.
> 
> If we really want to do it this way (and I suspect we don't)
> then the allocation attempt should be wrapped in PF_NOWARN
> to keep the messages away.

Yes, this is wanted.  It's readahead for xfs's btree structures and
it's supposed to fail instead of waking up kswapd or paging out
anything.  I already sent the PF_NOWARN patch to Chris, btw.

> And it should be changed to __GFP_HIGHMEM so XFS can perform
> readahead into highmem pages.

No.  that metadata must be mapped.

> However it is probably best to change this to just use 
> mapping->gfp_mask.  I vaguely recall that the nonblocking allocation
> improved performance in some situations, but it's quite possible
> that the VM problem which made that a good thing got fixed.

The mapping for xfs metadata is the bdev mapping, we really shouldn't
mess with it's gfp mask.