lkml.org 
[lkml]   [2002]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: discontiguous memory platforms
Date
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
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.099 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site