lkml.org 
[lkml]   [2004]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.6.9 Multiple Page Allocation Failures
Nathan Scott <nathans@sgi.com> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.056 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site