[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:
>> > 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
Main Index |
Thread Index |