[lkml]   [2001]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: __GFP_HIGH ignored?

On Sun, 2 Sep 2001, Daniel Phillips wrote:
> __GFP_HIGH is apparently ignored now. Its intended function is performed
> instead by PF_MEMALLOC. Should we take it out?

No. We may have a use for it in the future, especially as PF_MEMALLOC
really means something completely different.

I stronly suspect that the current PF_MEMALLOC handling is much too
strict: instead of trating a PF_MEMALLOC as a atomic high-priority thing,
we could treat it as something like

* recursive call? Make sure to strip out anything
* that could cause deadlocks and further recursion..
if (current->flags & PF_MEMALLOC) {
gfp_mask &= ~(__GFP_HIGHIO | __GFP_FS);
page = RMQUEUE(..)
if (page)
return page;
goto repeat;

(Yeah, not exactly like the above, but you get the idea - allow a very
limited form of recursion, and allow a PF_MEMALLOC to always use the
reserves - together they should make us better at handling the current
issues with bounce buffers, for example).

It may be that we'll never need __GFP_HIGH, but let's keep it - it does
have semantics that make some amount of sense.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.033 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site