xfs
[Top] [All Lists]

Re: Kernel 2.6.9 Multiple Page Allocation Failures

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: Kernel 2.6.9 Multiple Page Allocation Failures
From: Andrew Morton <akpm@xxxxxxxx>
Date: Thu, 2 Dec 2004 23:06:20 -0800
Cc: zaphodb@xxxxxxxxxxx, xhejtman@xxxxxxxxxxxx, marcelo.tosatti@xxxxxxxxxxxx, piggin@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: <20041203061835.GF1228@frodo>
References: <20041113144743.GL20754@xxxxxxxxxxx> <20041116093311.GD11482@xxxxxxxxxx> <20041116170527.GA3525@xxxxxxxxxxxx> <20041121014350.GJ4999@xxxxxxxxxxx> <20041121024226.GK4999@xxxxxxxxxxx> <20041202195422.GA20771@xxxxxxxxxxxx> <20041202122546.59ff814f.akpm@xxxxxxxx> <20041202210348.GD20771@xxxxxxxxxxxx> <20041202223146.GA31508@xxxxxxxxxxx> <20041202145610.49e27b49.akpm@xxxxxxxx> <20041203061835.GF1228@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Nathan Scott <nathans@xxxxxxx> wrote:
>
> > Nathan, it would be a worthwhile exercise to consider replacing GFP_ATOMIC
>  > with (GFP_ATOMIC & ~ __GFP_HIGH) where appropriate.
>  > ...
> 
>  (i.e. zero?  so future-proofing for if GFP_ATOMIC != __GFP_HIGH?)

yup.  (GFP_ATOMIC & ~ __GFP_HIGH) would mean "allocate atomically, but if
this means use emergency pools, then don't bother with that".

>  > If there are places in XFS where it only needs one of these two behaviours,
>  > it would be good to select just that one.
> 
>  OK, I took a quick look through - there's two places where we use
>  GFP_ATOMIC at the moment.  One is a log debug/tracing chunk of code,
>  wont be coming into play here, I'll go back and rework that later.
>  The second is in the metadata buffering code, and is in a spot where
>  we can cope with a failure (don't need to dip into emergency pools
>  at all) but looks like we're avoiding sleeping there.

Just two callsites?  That's less that I imagined.  Looks like my theory
comes unstuck.


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