Re: Merge of rmind-uvmplock branch

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

hi,

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

i guess the list can be too long for a large map entry.
probably it's better to start with a little more sophisticated structure.

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

sounds like a good idea.

> 
> - In the x86 pmap, we have a number retryable sequences when we operate in
>   the P->V direction.  pmap_page_remove() for instance.  I think these can
>   now be simplified as there are fewer concurrency issues, no need for
>   retryable sequences.  Yamamoto-san can you confirm?

i think so, yes.

YAMAMOTO Takashi