From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 2 May 2002 14:33:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 2 May 2002 14:33:39 -0400 Received: from dsl-213-023-038-046.arcor-ip.net ([213.23.38.46]:28064 "EHLO starship") by vger.kernel.org with ESMTP id ; Thu, 2 May 2002 14:33:38 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Roman Zippel Subject: Re: discontiguous memory platforms Date: Thu, 2 May 2002 20:32:07 +0200 X-Mailer: KMail [version 1.3.2] Cc: Andrea Arcangeli , Ralf Baechle , Russell King , linux-kernel@vger.kernel.org In-Reply-To: <3CD184BB.ED7F349F@linux-m68k.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 02 May 2002 20:26, Roman Zippel wrote: > Hi, > > Daniel Phillips wrote: > > > > Most of the time there are only a few nodes, I just don't know where and > > > how big they are, so I don't think a hash based approach will be a lot > > > faster. When I'm going to change this, I'd rather try the dynamic table > > > approach. > > > > Which dynamic table approach is that? > > I mean calculating the lookup table and patching the kernel at startup. Patching the kernel how, and where? Calculating the lookup table automatically at startup is definitely planned, and yes, essential to avoid an unmanageble proliferation of configuration files. It's also possible to pass the configuration as a list of mem=size@physaddr kernel command line entries, which is a pragmatic solution for configurations with unusual memory mappings, but not too many of them. > Anyway, I agree with Andrea, that another mapping isn't really needed. > Clever use of the mmu should give you almost the same result. We *are* making clever use of the mmu in config_nonlinear, it is doing the nonlinear kernel virtual mapping for us. Did you have something more clever in mind? -- Daniel