Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751724AbXBEQwQ (ORCPT ); Mon, 5 Feb 2007 11:52:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751722AbXBEQwQ (ORCPT ); Mon, 5 Feb 2007 11:52:16 -0500 Received: from waste.org ([66.93.16.53]:41013 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751718AbXBEQwP (ORCPT ); Mon, 5 Feb 2007 11:52:15 -0500 Date: Mon, 5 Feb 2007 10:38:47 -0600 From: Matt Mackall To: Arjan van de Ven Cc: Christoph Lameter , Andrew Morton , linux-kernel@vger.kernel.org, Nick Piggin , KAMEZAWA Hiroyuki , Rik van Riel Subject: Re: [RFC] Tracking mlocked pages and moving them off the LRU Message-ID: <20070205163847.GI16722@waste.org> References: <20070203005316.eb0b4042.akpm@linux-foundation.org> <1170525860.3073.1054.camel@laptopd505.fenrus.org> <20070203172242.e5bf2534.akpm@linux-foundation.org> <1170576977.3073.1100.camel@laptopd505.fenrus.org> <1170664774.3073.1236.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1170664774.3073.1236.camel@laptopd505.fenrus.org> User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1390 Lines: 34 On Mon, Feb 05, 2007 at 09:39:34AM +0100, Arjan van de Ven wrote: > On Sun, 2007-02-04 at 23:57 -0800, Christoph Lameter wrote: > > Hmmm.. I have had no time to test this one yet but I think this should > > work. It uses the delayed method and a new page flag PageMlocked() with > > different semantics. Fix for page migration is also included. > > > > Patch avoids to put new anonymous mlocked pages on the LRU. Maybe the same > > could be done for new pagecache pages? > > > > I still need a solution for the problem of not having enough page flag > > bits on i386 NUMA. > > I still don't get why you *really* need such a bit. There are three possibilities mentioned so far: 1) slow accounting - scan each attached VMA on each mmap/munmap 2) lazy accounting - the same as above, with the work all moved to the LRU sweep 3) accounting with an extra page flag - still needs to scan VMAs on munmap Christoph seems to prefer the third. I wonder if we couldn't stick a rough counter in address_space to fast-path the slow accounting - we'll typically only have 0 or 1 locks active. -- Mathematics is the supreme nostalgia of our time. - 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/