From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965890AbXCPU0E (ORCPT ); Fri, 16 Mar 2007 16:26:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965891AbXCPU0E (ORCPT ); Fri, 16 Mar 2007 16:26:04 -0400 Received: from dvhart.com ([64.146.134.43]:49826 "EHLO dvhart.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965890AbXCPU0B (ORCPT ); Fri, 16 Mar 2007 16:26:01 -0400 Message-ID: <45FAFD57.90601@mbligh.org> Date: Fri, 16 Mar 2007 13:25:59 -0700 From: Martin Bligh User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Christoph Lameter Cc: Andi Kleen , Steven Rostedt , Linus Torvalds , Ingo Molnar , linux-kernel@vger.kernel.org, Andrew Morton , Chris Wright , Rusty Russell , Glauber de Oliveira Costa , Andy Whitcroft Subject: Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2 References: <20070314050819.536207642@goodmis.org> <20070314125330.GA13168@elte.hu> <45F96B57.10206@mbligh.org> <20070315160648.GA11812@one.firstfloor.org> <1173977264.7922.24.camel@localhost.localdomain> <20070316114415.GA26403@one.firstfloor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > On Fri, 16 Mar 2007, Andi Kleen wrote: > >>> x86_64 is going to acquire more functionality that will not be available >>> for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual >> What advantage would that have over the current setup? >> We already should handle holes between nodes reasonably efficiently >> and with nonlinear memory even holes inside nodes shouldn't be a problem. > > It is primarily a performance improvement since the sparsemem table > lookups would no longer be necessary and it also streamlines other > frequent cacheline uses. These page -> page_struct and vice versa > operations are key to the performance of various subsystem among them > the slab allocator. cc: apw You have to do some sort of lookup anyway, and Andy seemed to have them all folded into one. Or are you trying to avoid this by going to back to the crud we had in 2.4 where we pretend mem_map is one big array, indexed by pfn with huge sparsely mapped holes in it? Would be nice to work out (and document somewhere) what the pros and cons of virtual memmap vs sparsemem were - ISTR one of the arguments was extremely sparsely layed out machines, and you needed sparsemem for that. But right now we have 3 solutions, which is not a good situation.