The __GFP_HIGH, GFP_ATOMIC, __GFP_WAIT flags are still driving me bonkers.
It seems to me that:
1) __GFP_WAIT is supposed to mean can wait, and __alloc_pages()
keys off that bit to set its "wait" variable. Good so far.
2) __GFP_HIGH is supposed to mean can access emergency pools
(use lower watermarks), and __alloc_pages() does that. Also
good so far.
3) But gfp.h defines GFP_ATOMIC to be an alias for __GFP_HIGH,
and many callers through out the kernel use GFP_ATOMIC to mean
"can't sleep" or "can't wait" or some such. These folks are
not getting the service they expect - they are asking for the
most aggressive form of allocation (short perhaps of the
special case for allocations that will net free more memory
than they require, such as exiting), and they get the half way
improvement instead, with the possibility of sleeping (!).
The confusion even extends to the comments in __alloc_pages(),
such as in the lines:
/* Atomic allocations - we can't balance anything */
if (!wait)
goto nopage;
The "!wait" condition is --not-- GFP_ATOMIC, which is what
one might think was meant by "Atomic allocations", and likely
what the many users of GFP_ATOMIC were expecting - a nopage
response in such cases.
Perhaps GFP_ATOMIC should be its own __GFP_ATOMIC bit, with a BUG_ON
if both __GFP_ATOMIC and __GFP_WAIT are set at the same time,
leaving __GFP_HIGH for the few uses where people were just asking
to go a bit lower in the reserves.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
