xfs
[Top] [All Lists]

Re: xfsdump stuck in io_schedule

To: Andrew Morton <akpm@xxxxxxxxx>
Subject: Re: xfsdump stuck in io_schedule
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 18 Nov 2002 12:54:16 +0000
Cc: zlatko.calusic@xxxxxxxx, Stephen Lord <lord@xxxxxxx>, Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <3DD7F7CB.F292C9C7@digeo.com>; from akpm@digeo.com on Sun, Nov 17, 2002 at 12:10:51PM -0800
References: <dnlm3v9ebk.fsf@magla.zg.iskon.hr> <20021115140635.A31836@wotan.suse.de> <dnr8dmj1i1.fsf@magla.zg.iskon.hr> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> <87n0o8c7g5.fsf@atlas.iskon.hr> <3DD7F7CB.F292C9C7@digeo.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
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.


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