Messages in this thread | | | Date | Thu, 2 Dec 2004 23:06:20 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |