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_launder(gfp_mask);
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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:42 EST