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
