Re: Merge of rmind-uvmplock branch

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
> >> the idea is to protect pv chains with object lock, right?
> >> is the new locking protocol documented anywhere?
> > 
> > Right, object associated with the page (UVM object or anon).  That can
> > be asserted by pmaps using a new uvm_page_locked_p() routine.
> > 
> > Protocol is not yet documented.  Note about extra synchronisation
> > provided by UVM can go into pmap(9) man page.  Do you have a good
> > suggestion where to document it in the code?
> 
> how about uvm_object.h?

OK, will add some description.

> btw, faulting code locks amap first and then object.
> uvm_map_lock_entry seems to lock them in a reversed order.  is it safe?

That is a bug.  Fixed.  Code paths locked by this routine are small enough,
which is probably a reason why stress tests did not trigger the deadlock.

> > As stated in other forum, ->A loaning is unused for 13 years, has
> > try-lock issue, and loaning in general has performance problems on SMP
> > systems due to expensive TLB flushes (and IPIs).  The concept needs to
> > be revisited. It is not in the scope of this branch, so O->A loaning
> > just gets disabled.
> > 
> > Thinking about page ownership changes in general - transitions should be
> > done atomically.  With loaning, currently, there is a case when a page
> > can be owner-less (if owner disappears, while page is loaned).  In such
> > case page ownership should be taken before meta-data changes, and thus
> > relevant locks retain acquired for pmap(9) as well.  However, locking
> > protocol for O->A loaning really depends on how (if?) we are going to
> > fix it..
> 
> while i personally don't cry if O->A loaning is disposed, it's good to
> make it clear.  iirc chuq wanted to keep the functionality.

Right.  Chuck did not respond to the last email on this issue, though..

-- 
Mindaugas