Messages in this thread | | | Date | Wed, 13 Apr 2005 11:13:29 +1000 | From | Nick Piggin <> | Subject | Re: [patch 3/9] no PF_MEMALLOC tinkering |
| |
Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> 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 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/
| |