Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 30 Jan 2002 04:08:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 30 Jan 2002 04:08:07 -0500 Received: from waldorf.cs.uni-dortmund.de ([129.217.4.42]:25779 "EHLO waldorf.cs.uni-dortmund.de") by vger.kernel.org with ESMTP id ; Wed, 30 Jan 2002 04:07:56 -0500 Message-Id: <200201300907.g0U97icL001965@tigger.cs.uni-dortmund.de> To: Daniel Phillips cc: linux-kernel Subject: Re: Note describing poor dcache utilization under high memory pressure In-Reply-To: Message from Daniel Phillips of "Tue, 29 Jan 2002 13:33:57 +0100." Date: Wed, 30 Jan 2002 10:07:44 +0100 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Daniel Phillips said: > On January 29, 2002 12:54 pm, Helge Hafting wrote: > > Momchil Velikov wrote: [...] > > > Umm, all the ptes af the parent ought to be made COW, no ? > > Sure. But quite a few of them may be COW already, if the parent > > itself is a result of some earlier fork. > Right, or if the parent has already forked at least one child. But most of this will be lost on exec(2). Also, it is my impression that the tree of _running_ processes isn't usually very deep (Say init --> X --> [Random processes] --> [compilations &c], this would make 5 or 6 deep, no more. Should take a pstree(1) listing on a busy machine and work out some statistics... here (a personal worstation) the tree is very fat at the first level below init(8), and just 5 deep when running pstree(1)). Sure, all processes will all end up sharing glibc, and the graphical stuff will share the X &c libraries, so this would end up being a win this way. -- Horst von Brand http://counter.li.org # 22616 - 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/