From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cantor.suse.de ([195.135.220.2]:40989 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id ed: from cantor.suse.de ([195.135.220.2]:40989 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753170AbXESBaS (ORCPT ); Fri, 18 May 2007 21:30:18 -0400 Date: Sat, 19 May 2007 03:30:13 +0200 From: Nick Piggin Subject: Re: [rfc] increase struct page size?! Message-ID: <20070519013013.GC15569@wotan.suse.de> References: <20070518040854.GA15654@wotan.suse.de> <7554.1179481350@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7554.1179481350@redhat.com> Sender: linux-arch-owner@vger.kernel.org To: David Howells Cc: Linux Kernel Mailing List , Linux Memory Management List , linux-arch@vger.kernel.org List-ID: On Fri, May 18, 2007 at 10:42:30AM +0100, David Howells wrote: > Nick Piggin wrote: > > > I'd like to be the first to propose an increase to the size of struct page > > just for the sake of increasing it! > > Heh. I'm surprised you haven't got more adverse reactions. > > > If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes, > > which is quite a nice number for cache purposes. > > Whilst that's true, if you have to deal with a run of contiguous page structs > (eg: the page allocator, perhaps) it's actually less efficient because it > takes more cache to do it. But, hey, it's a compromise whatever. > > In the scheme of things, if we're mostly dealing with individual page structs > (as I think we are), then yes, I think it's probably a good thing to do - > especially with larger page sizes. Yeah, we would end up eating about 12.5% more cachelines for contiguous runs of pages... but that only kicks in after we've touched 8 of them I think, and by that point the accesses should be very prefetchable. I think the average of 75% more cachelines touched for random accesses is going to outweigh the contiguous batch savings, but that's just a guess at this point. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From linux-arch-owner@vger.kernel.org Mon May 21 00:56:59 2007 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on hancock.sc.steeleye.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,INFO_TLD, PLING_QUERY autolearn=no version=3.1.3 X-Original-To: james.bottomley@steeleye.com Delivered-To: james.bottomley@steeleye.com Received: from orville.steeleye.com (orville.steeleye.com [71.30.118.242]) by hancock.sc.steeleye.com (Postfix) with ESMTP id 3A615AAA822C for ; Mon, 21 May 2007 00:56:54 -0400 (EDT) Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by orville.steeleye.com (8.12.8/8.12.8) with ESMTP id l4L4upam004681 for ; Mon, 21 May 2007 00:56:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759220AbXESPnZ (ORCPT ); Sat, 19 May 2007 11:43:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759275AbXESPnY (ORCPT ); Sat, 19 May 2007 11:43:24 -0400 Received: from hellhawk.shadowen.org ([80.68.90.175]:1523 "EHLO hellhawk.shadowen.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759220AbXESPnY (ORCPT ); Sat, 19 May 2007 11:43:24 -0400 Received: from localhost ([127.0.0.1]) by hellhawk.shadowen.org with esmtp (Exim 4.50) id 1HpRGO-0002VA-BC; Sat, 19 May 2007 16:54:36 +0100 Message-ID: <464F1B21.8020408@shadowen.org> Date: Sat, 19 May 2007 16:43:29 +0100 From: Andy Whitcroft User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Christoph Lameter CC: Linux Kernel Mailing List , Linux Memory Management List , linux-arch@vger.kernel.org, Nick Piggin Subject: Re: [rfc] increase struct page size?! (now sparsemem vmemmap) References: <20070518040854.GA15654@wotan.suse.de> <20070519012530.GB15569@wotan.suse.de> In-Reply-To: X-Enigmail-Version: 0.94.2.0 OpenPGP: url=http://www.shadowen.org/~apw/public-key Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-arch@vger.kernel.org Christoph Lameter wrote: > On Sat, 19 May 2007, Nick Piggin wrote: > >> Hugh points out that we should make _count and _mapcount atomic_long_t's, >> which would probably be a better use of the space once your vmemmap goes >> in. > > Well Andy was going to merge it: > > http://marc.info/?l=linux-kernel&m=117620162415620&w=2 > > Andy when are we going to get the vmemmap patches into sparsemem? Sorry this has been backed up with all the too-ing and fro-ing on other things. I am just cleaning up the next round which includes feedback from wli and first stab at PPC64 support. Should be out monday for review. -apw