Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 29 Jan 2002 11:57:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 29 Jan 2002 11:57:44 -0500 Received: from waste.org ([209.173.204.2]:60102 "EHLO waste.org") by vger.kernel.org with ESMTP id ; Tue, 29 Jan 2002 11:57:28 -0500 Date: Tue, 29 Jan 2002 10:57:04 -0600 (CST) From: Oliver Xymoron To: Rik van Riel cc: Daniel Phillips , Linus Torvalds , Josh MacDonald , linux-kernel , , Subject: Re: Note describing poor dcache utilization under high memory pressure In-Reply-To: Message-ID: 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 Tue, 29 Jan 2002, Rik van Riel wrote: > On Mon, 28 Jan 2002, Oliver Xymoron wrote: > > > Somewhere in here, the pages have got to all be marked read-only or > > something. If they're not, then either parent or child writing to > > non-faulting addresses will be writing to shared memory. > > Either that, or we don't populate the page tables of the > parent and the child at all and have the page tables > filled in at fault time. That's very nearly what I proposed in the second half of my message (with the exception that we ought to pre-fault the current stack and code page tables as we're sure to need these immediately). Daniel's approach seems to be workable (once he's spelled out all the details) but it misses the big performance win for fork/exec, which is surely the common case. Given that exec will be throwing away all these mappings, we can safely assume that we will not be inheriting many shared mappings from parents of parents so Daniel's approach also still ends up marking most of the pages RO still. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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/