| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: Kernel 2.6.9 Multiple Page Allocation Failures, Nathan Scott |
|---|---|
| Next by Date: | Re: Kernel 2.6.9 Multiple Page Allocation Failures, Christoph Hellwig |
| Previous by Thread: | Re: Kernel 2.6.9 Multiple Page Allocation Failures, Nathan Scott |
| Next by Thread: | Re: Kernel 2.6.9 Multiple Page Allocation Failures, Lukas Hejtmanek |
| Indexes: | [Date] [Thread] [Top] [All Lists] |