tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: page color initialization

On Fri, Sep 30, 2011 at 1:13 PM, matthew green <> 
>> 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.


- 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.)

Home | Main Index | Thread Index | Old Index