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