Re: Merge of rmind-uvmplock branch

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

hi,

> yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
>> > Unless anyone objects, I will merge rmind-uvmplock branch.  The
>> > technical objectives of the branch are described here:
>> > 
>> > http://nxr.netbsd.org/xref/src/doc/BRANCHES?r=1.307#488
>> 
>> 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?

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

> 
>> i'm curious about the consequence for O->A loaning.
>> or anything which can change the owner of pages.
> 
> 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.

YAMAMOTO Takashi

> 
>> 
>> YAMAMOTO Takashi
> 
> -- 
> Mindaugas