Re: [PATCH trivial] block: GFP_ATOMIC is __GFP_HIGH

[Jens Axboe]

On Sun, Jun 29 2008, Eduard - Gabriel Munteanu wrote:
> On Sun, 29 Jun 2008 07:16:49 +0100 (BST)
> Hugh Dickins <hugh@xxxxxxxxxxx> 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 have to agree with Eduard here - GFP_ATOMIC means "don't block"
primarily, whether it has a given priority or not is something you would
have to look up. So it's more readable with the __GFP_HIGH manually
added.

> > 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.

It's not a big deal, it'll recover fine.

-- 
Jens Axboe

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