Date: Tue, 12 Apr 2005 12:57:01 -0700
From: Andrew Morton <akpm@osdl.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: axboe@suse.de, linux-kernel@vger.kernel.org, kenneth.w.chen@intel.com
Subject: Re: [patch 3/9] no PF_MEMALLOC tinkering
Message-Id: <20050412125701.40fe5c70.akpm@osdl.org>
In-Reply-To: <425BC3D2.3020909@yahoo.com.au>
References: <425BC262.1070500@yahoo.com.au>
	<425BC3D2.3020909@yahoo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1142
Lines: 33

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.

Now if we were to add __GFP_NOMEMALLOC in add_to_swap() then things would
work as we want them to.


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.


-
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/