Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 1 Oct 2001 07:14:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 1 Oct 2001 07:14:21 -0400 Received: from humbolt.nl.linux.org ([131.211.28.48]:33037 "EHLO humbolt.nl.linux.org") by vger.kernel.org with ESMTP id ; Mon, 1 Oct 2001 07:14:12 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Rik van Riel , Mike Fedyk Subject: Re: 2.4.9-ac16 good perfomer? Date: Mon, 1 Oct 2001 13:14:28 +0200 X-Mailer: KMail [version 1.3.1] Cc: In-Reply-To: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20011001111435Z16281-2757+2605@humbolt.nl.linux.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On September 29, 2001 03:20 am, Rik van Riel wrote: > > Is it normal to have Inact_target 1/4 of main memory (64MB of 256MB RAM)? > > In previous versions, this value would fluctuate with the load of the > > system. > > > > Is this expected? > > Yes, this is a 'compensation' for the fact that page aging changed > from exponential to linear. The combination of linear page aging > with a large inactive_target results in a good combination of > frequency- and recency-based page eviction. > > Doing just linear page aging with a small inactive target resulted > in worse throughput than exponential page aging for some workloads, > better for other workloads. Linear page aging with a large inactive > target results in good througput and latency under all workloads I've > found up to now. As usual, thanks go out to Matt Dillon for finding > this balancing point. Nice. With this under control, another feature of his memory manager you could look at is the variable deactivation threshold, which makes a whole lot more sense now that the aging is linear. To implement it efficiently PAGE_AGE_DECL just needs to be a variable, since in effect the deactivation threshold already is exactly PAGE_AGE_DECL. How to set this variable is a deep and interesting question. Matt had his ideas on that as you know, and in fact it's a key feature of the BSD mm it, but it's far from clear that the BSD arrangement could be used directly in Linux. There are a number of obvious difficulties: no reverse map, highmem, more caches to balance, and so on. However, it's intuitively clear that the mm sweet spot can be made bigger by controlling the DECL variable, i.e., we can push the thrash point further out for a wider variety of loads. Obligatory disclaimer: there is no burning issue here; this is a *developmental* idea. -- Daniel - 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/