tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Merge of rmind-uvmplock branch


> (YAMAMOTO Takashi) wrote:
>> > Unless anyone objects, I will merge rmind-uvmplock branch.  The
>> > technical objectives of the branch are described here:
>> > 
>> >
>> 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
> -- 
> Mindaugas

Home | Main Index | Thread Index | Old Index