[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 <mrg%eterna.com.au@localhost>
>> 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
>> 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
>> - 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.)
Main Index |
Thread Index |