Re: uvm ncolors [was: CVS commit: src/sys/arch/x86/x86]

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

simonb%NetBSD.org@localhost wrote:

> Can we _always_ assume that?  At first, I thought a 6MB 16-way
> associative cache made more sense than a 24-way cache.  Is a 6MB
> 16-way cache impossible to do?

It might be possible, but it requires non-power-of-two indexes
and more extra hardware (than odd ways) on lookup so it's quite
unlikely, I think.

> This I'm also not sure about :-)  If we really do have 96 colours,
> will using 32 be better than 1 or not?

As I wrote before, current coloring code only works as intended
only if ncolors is actually a power of two and we can assume
cache indexes are looked up by lower bits of physical address
(i.e. by modulo). If there is a CPU which has actually odd indexes,
it would have special PA -> index mappings and current coloring
code can't handle it properly.

> As an aside, I did do some testing with ncolors = {1,2,32,64}
> with build.sh and can't really see any difference anyway...

If the CPU has an enough large number of set associative ways,
the effect of coloring might be almost invisible because
the intension of coloring is just to reduce possible conflicts
on cache index lookups. (see Schimmel's book section 7.2.3)

> > - but no need to panic in that case otherwise we'll get
> >   possible panics on each brandnew CPU unless MD cache
> >   detection code like intel_cpuid_cache_info[] is always
> >   up-to-date
> 
> Agreed.  My current patch doesn't panic at all.

But it still better to show some warnings in that case.
---
Izumi Tsutsui