Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756831AbXHUWch (ORCPT ); Tue, 21 Aug 2007 18:32:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751971AbXHUWc1 (ORCPT ); Tue, 21 Aug 2007 18:32:27 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:56991 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751206AbXHUWc1 (ORCPT ); Tue, 21 Aug 2007 18:32:27 -0400 Date: Tue, 21 Aug 2007 15:32:25 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Rik van Riel cc: Peter Zijlstra , linux-mm@kvack.org, dkegel@google.com, akpm@linux-foundation.org, Nick Piggin , ak@suse.de, linux-kernel@vger.kernel.org Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks In-Reply-To: <46CB5C89.2070807@redhat.com> Message-ID: References: <20070820215040.937296148@sgi.com> <1187692586.6114.211.camel@twins> <1187730812.5463.12.camel@lappy> <46CB5C89.2070807@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1959 Lines: 46 On Tue, 21 Aug 2007, Rik van Riel wrote: > Christoph Lameter wrote: > > > I want general improvements to reclaim to address the issues that you see > > and other issues related to reclaim instead of the strange code that makes > > PF_MEMALLOC allocs compete for allocations from a single slab and putting > > logic into the kernel to decide which allocs to fail. We can reclaim after > > all. Its just a matter of finding the right way to do this. > > The simplest way of achieving that would be to allow > recursion of the page reclaim code, under the condition > that the second level call can only reclaim clean pages, > while the "outer" call does what the VM does today. Yes that is what the precursor to this patchset does. See http://marc.info/?l=linux-mm&m=118710207203449&w=2 This one did not even come up to the level of the earlier one. Sigh. The way forward may be: 1. Like in the earlier patchset allow reentry to reclaim under PF_MEMALLOC if we are out of all memory. 2. Do the laundry as here but do not write out laundry directly. Instead move laundry to a new lru style list in the zone structure. This will allow the recursive reclaim to also trigger writeout of pages (what this patchset was supposed to accomplish). 3. Perform writeback only from kswapd. Make other threads wait on kswapd if memory is low, we can wait and writeback still has to progress. 4. Then allow reclaim of GFP_ATOMIC allocs (see http://marc.info/?l=linux-kernel&m=118710595617696&w=2). Atomic reclaim can then also put pages onto the zone laundry lists from where it is going to be picked up and written out by kswapd ASAP. This one may be tricky so maybe keep this separate. - 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/