Messages in this thread | | | Date | Sun, 29 Jun 2008 17:15:28 +0300 | From | Eduard - Gabriel Munteanu <> | Subject | Re: [PATCH trivial] block: GFP_ATOMIC is __GFP_HIGH |
| |
On Sun, 29 Jun 2008 07:16:49 +0100 (BST) Hugh Dickins <hugh@veritas.com> wrote:
> but it is not > accidental that GFP_ATOMIC includes __GFP_HIGH - it's precisely when > we're atomic that we need access to those extra reserves; and where > we don't actually want them then we do say GFP_NOWAIT not GFP_ATOMIC.
I would expect GFP_ATOMIC just prevents sleeping, while it _could_ fail (in theory) unless it is allowed to touch the emergency pools.
Actually, in many/most atomic contexts bail-out paths are possible for allocation failures. And many/most of these atomic contexts have no special reason to require emergency memory. Think about the usual allocations enclosed within spinlocks.
> I expect the gfp flags will change in the future; but unless I missed > somewhere, amongst all the places which specify GFP_ATOMIC throughout > the kernel, this is the only one which ors in __GFP_HIGH too. I don't > believe it expected access to extra extra reserves! So I thought we'd > do best to remove the anomaly.
Yes, it seems this is the only place where this occurs.
Although I did not read all the code and resolved its implications, it seems like it actually needs something like __GFP_NOFAIL (?) instead of __GFP_HIGH. The slab itself is created with SLAB_PANIC.
> (But what I'd actually intended to grep for was __GFP_HIGHMEM.) > > Hugh
Eduard
| |