Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbXBDBtd (ORCPT ); Sat, 3 Feb 2007 20:49:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751864AbXBDBtc (ORCPT ); Sat, 3 Feb 2007 20:49:32 -0500 Received: from omx1-ext.sgi.com ([192.48.179.11]:50503 "EHLO omx1.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751846AbXBDBtc (ORCPT ); Sat, 3 Feb 2007 20:49:32 -0500 Date: Sat, 3 Feb 2007 17:49:13 -0800 (PST) From: Christoph Lameter To: Andrew Morton cc: Arjan van de Ven , linux-kernel@vger.kernel.org, Nick Piggin , KAMEZAWA Hiroyuki , Rik van Riel Subject: Re: [RFC] Tracking mlocked pages and moving them off the LRU In-Reply-To: <20070203172242.e5bf2534.akpm@linux-foundation.org> Message-ID: References: <20070203005316.eb0b4042.akpm@linux-foundation.org> <1170525860.3073.1054.camel@laptopd505.fenrus.org> <20070203172242.e5bf2534.akpm@linux-foundation.org> 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: 1378 Lines: 29 On Sat, 3 Feb 2007, Andrew Morton wrote: > Do we actually need NR_MLOCK? Page reclaim tends to care more about the > size of the LRUs and doesn't have much dependency on ->present_pages, Yes, we'd be fine with general reclaim I think. But the calculation of the dirty ratio based on ZVCs would need it if we take the mlocked pages off. Otherwise we may have dirty ratios > 100%. > I guess we could use NR_MLOCK for writeback threshold calculations, to > force writeback earlier if there's a lot of mlocked memory in the affected > zones. But that code isn't zone-aware anyway, and we don't know how to make > it zone aware in any sane fashion and making it cpuset-aware isn't very > interesting or useful.. Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific number of mlocked pages. The nice thing about ZVCs is that it allows easy access to counts on different levels. > So.. Why do we want NR_MLOCK? Rik also had some uses in mind for allocation? - 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/