Source-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: uvm ncolors [was: CVS commit: src/sys/arch/x86/x86]
simonb%NetBSD.org@localhost wrote:
> OK to back this out and apply this one instead? I'll probably change
> the wording in the comment slightly. I also had the panic in an #ifdef
> DIAGNOSTIC, but now think that it's worth enabling all the time - the
> lossage mode when this is wrong isn't obvious.
I think it's better to fallback to ncolors=1 with
some warnings in case of !powerof2(ncolors) because:
- we could assume (n_cache_index * cache_line_size) is
always a power of two if the CPU has a sane design
(unless MD cache detection code has some bug)
- if the CPU has a really odd number of cache indexes,
our current page coloring code can't handle it properly
and the only sane way is disabling the optimization
- 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
Maybe we need the similar check in uvm_page_init().
---
Izumi Tsutsui
Home |
Main Index |
Thread Index |
Old Index