On Thursday 02 May 2002 20:26, Roman Zippel wrote:
> 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
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:14 EST