lkml.org 
[lkml]   [2008]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-06-29 16:19    [W:0.060 / U:1.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site