Re: Merge of rmind-uvmplock branch

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On Jun 14, 2011, at 8:52 AM, Andrew Doran wrote:
> 
>> Mindaugas, thank you very much for your hard work!!
>> 
>> On Tue, Jun 07, 2011 at 03:16:06AM +0000, YAMAMOTO Takashi wrote:
>> 
>>> the idea is to protect pv chains with object lock, right?
>> 
>> That was the initial driver for me anyway.
>> 
>> Now that this work is in, there are some changes that can be built upon it
>> to realise the full value -- and hopefully make exit() etc. very cheap.
>> Looking at this from an x86 perspective but some of the ideas will apply
>> to other ports:
>> 
>> - My initial idea was to kill the global PV hash and associated locks.  To
>>  replace this we would embed a list head in each uvm_map_entry (or wherever
>>  else a mapping is managed).  This would be supplied by the caller on each
>>  relevant pmap call - pmap_enter() and so on.  PV entries would be added to
>>  and removed from this structure by the pmap module.  An initial
>>  implementation could get away with a dumb linked list I think.
> 
> So if there is no global P->V list for a page, how do pmap_page_protect and 
> friends work?  That is the point of the PV entry after all.
> 
> For doing V->P, the phys_addr is gotten from accessing the page table and 
> then a P->V lookup is done.

which port do you have in mind?

for x86, MDPAGE has a list of its pv entries and most or all P->V ops use it.
the global hash is there to help pmap_remove to find a specific pv entry
quickly.

YAMAMOTO Takashi

> 
>> - So then PV entries tracked with the mapping instead of globally. Once
>>  pmap_remove_all() has been called pmap_remove() could switch to a
>>  "shortcut" mode and become very quick.  From memory I believe all it would
>>  need to do is tear down the software PV entries, and not touch any page or
>>  pmap state.  Tearing down pmap state would be deferred to pmap_destroy(). 
>>  At that point we can then clear out the pmap's uvm_objects and free all
>>  pmap pages in bulk.  This would avoid potentially thousands of expensive
>>  scans and atomic updates to the hardware paging structures, which account
>>  for the bulk of expense during exit() etc.  If the system is short on
>>  memory we might want a mechanism to switch CPUs away from this pmap if
>>  they are hanging onto it as pmap_kernel - i.e. preventing pmap_destroy()
>>  from being called.
> 
> Still don't have a good algorithm for pmap_remove_all.  Walking the page 
> tables isn't very fast since the p->v overhead is annoying.