Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
PF_MEMALLOC is really not a tool for tinkering. It is pretty specifically
used to prevent recursion into page reclaim, and to prevent low memory
deadlocks.
The mm/swap_state.c code was the only legitimate tinkerer. Its concern
was addressed by the previous patch.
What previous patch? radix tree allocation doesn't use mempools, so this
patch will cause add_to_swap() to oom the machine with radix tree node
allocations.
Sorry, just assumed they did fromt that comment.
Now if we were to add __GFP_NOMEMALLOC in add_to_swap() then things would
work as we want them to.
That would be good.
The dm_crypt change looks OK.
The code in mpage.c is saying "if we failed to allocate a correctly-sized
bvec and if we're doing pageout then try to allocate a smaller-sized bvec
instead".
It's probably fairly useless, but afaict there's nothing in any of the
other patches here which makes it redundant.
Well, I didn't like it because it uses mempools anyway, so it
might as well just wait for its allocation.
My motivation is to remove all external users of PF_MEMALLOC,
really.
But it looks like in this case, the code is dead anyway, because
mempool_alloc will never return NULL if it is passed __GFP_WAIT.
--
SUSE Labs, Novell Inc.
-
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/
