Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 30 Jan 2002 10:55:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 30 Jan 2002 10:55:28 -0500 Received: from garrincha.netbank.com.br ([200.203.199.88]:41988 "HELO netbank.com.br") by vger.kernel.org with SMTP id ; Wed, 30 Jan 2002 10:55:10 -0500 Date: Wed, 30 Jan 2002 13:54:59 -0200 (BRST) From: Rik van Riel X-X-Sender: To: Daniel Phillips Cc: Horst von Brand , linux-kernel Subject: Re: Note describing poor dcache utilization under high memory pressure In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.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 On Wed, 30 Jan 2002, Daniel Phillips wrote: > On January 30, 2002 03:46 pm, Rik van Riel wrote: > > On Wed, 30 Jan 2002, Daniel Phillips wrote: > > > |-bash---bash---xinit-+-XFree86 > > > | `-xfwm-+-xfce---gnome-terminal-+-bash---pstree > > > > It doesn't matter how deep the tree is, on exec() all > > previously shared page tables will be blown away. > > > > In this part of the tree, I see exactly 2 processes > > which could be sharing page tables (the two bash > > processes). > > Sure, your point is that there is no problem and the speed of rmap on > fork is not something to worry about? No. The point is that we should optimise for fork()+exec(), not for a long series of consecutive fork()s all sharing the same page tables. regards, Rik -- "Linux holds advantages over the single-vendor commercial OS" -- Microsoft's "Competing with Linux" document http://www.surriel.com/ http://distro.conectiva.com/ - 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/