Re: page color initialization

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Sep 30, 2011 at 1:13 PM, matthew green <mrg%eterna.com.au@localhost> 
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.)