[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Merge of rmind-uvmplock branch
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..
Main Index |
Thread Index |