On Fri, Sep 30, 2011 at 1:13 PM, matthew green <[email protected]> wrote: > >> The current code seems to allow to change uvmexp.ncolors at >> configure() -> cpu_attach() -> uvm_page_recolor(). I think changing >> uvmexp.ncolors after uvm_init() is too late, and allocating such >> fundamental data like page freelist buckets that late is best to >> avoid. >> >> How about: >> >> - determine cache size in MD boot code, by querying the primary CPU >> (supposing that this should not need lots of infrastructure like >> dynamic memory allocation / bus interaction) > > primary CPU isn't good enough for this task.
Could you elaborate more? Any concrete counter-example? >> - determine uvmexp.ncolors before calling >> init_main()/uvm_init()/uvm_page_init() >> >> - if configure() finds a CPU whose cache size doesn't match the >> primary CPU, just reject to attach it > > what actual problem are you worried about here? besides this > new bug, what else is wrong? Complexity, non-determinism, lack of design. Questions: - is there any architecture which allows MP with different cache-line sizes? - if yes, does NetBSD support it? (or any plan/intention?) - does NetBSD allow CPU attach/detach at run-time? (or any plan/intention?) - how about VIPT, where page-color aware remapping is mandatory now? (Allocating these important data structures in uvm_page.c by calling malloc(9) is just plain wrong IMO.)
