Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 22 Oct 2002 15:03:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 22 Oct 2002 15:03:30 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]:58553 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id ; Tue, 22 Oct 2002 15:02:37 -0400 Date: Tue, 22 Oct 2002 12:02:27 -0700 From: "Martin J. Bligh" To: Bill Davidsen cc: Rik van Riel , "Eric W. Biederman" , Dave McCracken , Andrew Morton , Linux Kernel , Linux Memory Management Subject: Re: [PATCH 2.5.43-mm2] New shared page table patch Message-ID: <407130000.1035313347@flay> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2073 Lines: 44 >> > Actually, per-object reverse mappings are nowhere near as good >> > a solution as shared page tables. At least, not from the points >> > of view of space consumption and the overhead of tearing down >> > the mappings at pageout time. >> > >> > Per-object reverse mappings are better for fork+exec+exit speed, >> > though. >> > >> > It's a tradeoff: do we care more for a linear speedup of fork(), >> > exec() and exit() than we care about a possibly exponential >> > slowdown of the pageout code ? > > That tradeoff makes the case for spt being a kbuild or /proc/sys option. A > linear speedup of fork/exec/exit is likely to be more generally useful, > most people just don't have huge shared areas. On the other hand, those > who do would get a vast improvement, and that would put Linux a major step > forward in the server competition. > >> As long as the box doesn't fall flat on it's face in a jibbering >> heap, that's the first order of priority ... ie I don't care much >> for now ;-) > > I'm just trying to decide what this might do for a news server with > hundreds of readers mmap()ing a GB history file. Benchmarks show the 2.5 > has more latency the 2.4, and this is likely to make that more obvious. > > Is there any way to to have this only on processes which really need it? > define that any way you wish, including hanging a capability on the > executable to get spt. Uh, what are you referring to here? Large pages or shared pagetables? You can't mmap filebacked stuff with larged pages (nixed by Linus). And yes, large pages have to be specified explicitly by the app. On the other hand, I don't think shared pagetables have an mmap hook, though that'd be easy enough to add. And if you're not reading the whole history file, presumably the PTEs will only be sparsely instantiated anyway. M. - 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/