From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S273809AbRIRCct>; Mon, 17 Sep 2001 22:32:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S273810AbRIRCcm>; Mon, 17 Sep 2001 22:32:42 -0400
Received: from perninha.conectiva.com.br ([200.250.58.156]:58896 "HELO
	perninha.conectiva.com.br") by vger.kernel.org with SMTP
	id <S273809AbRIRCc0> convert rfc822-to-8bit; Mon, 17 Sep 2001 22:32:26 -0400
Date: Mon, 17 Sep 2001 22:08:22 -0300 (BRT)
From: Marcelo Tosatti <marcelo@conectiva.com.br>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrea Arcangeli <andrea@suse.de>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.21.0109172016200.6823-100000@freak.distro.conectiva>
Message-ID: <Pine.LNX.4.21.0109172156490.6905-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org



On Mon, 17 Sep 2001, Marcelo Tosatti wrote:

> 
> 
> On Mon, 17 Sep 2001, Linus Torvalds wrote:
> 
> > 
> > Ok, the big thing here is continued merging, this time with Andrea.
> > 
> > I still don't like some of the VM changes, but integrating Andrea's VM
> > changes results in (a) better performance and (b) much cleaner inactive
> > page handling in particular. Besides, for the 2.4.x tree, the big priority
> > is stability, we can re-address my other concerns during 2.5.x.
> 
> Andrea, 
> 
> Could you please make a resume of your VM changes ? 
> 
> Its hard to keep up with VM changes this way. 

Andrea, 

I've just read a bit of your new VM code and I have a few comments.

You completly removed the "inactive freeable pages" logic: There is no
more distiction between "freeable inactive" and "free" pages. All VM work
is based on "freepages.high" watermark. I don't like that: it seems to
make page freeing more aggressive over time.

Also, if we have several try_to_free_pages() callers, for different
classzones, I'm right saying that a caller with a "smaller" classzone can
"hide" pages in its "active_local_lru" and/or "inactive_local_lru" (during
shrink_cache) from other processes trying to free pages from those higher
zones ?