tech-kern archive

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

Re: O->A loan



hi,

thanks for benchmark!

was it without DIAGNOSTIC?

YAMAMOTO Takashi

> Hello Yamamoto-san,
> 
> I ran dbench on the same system with yamt-pagecache, yamt-pagecache 
> without a-o loan, and yamt-pagecache-base3.
> http://linbsd.org/yamt.png
> The tests were run three times on each kernel and the results were 
> consistent between reboots/runs.
> 
> Thanks.
> 
> On Tue, 27 Dec 2011, YAMAMOTO Takashi wrote:
> 
>> Date: Tue, 27 Dec 2011 02:53:29 +0000 (UTC)
>> From: YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost>
>> To: chuq%chuq.com@localhost
>> Cc: tech-kern%netbsd.org@localhost
>> Subject: Re: O->A loan
>> 
>> hi,
>>
>> i made read with O->A loaning work for easy cases (ie. no locking difficulty)
>> on yamt-pagecache branch so that someone interested can benchmark.
>>
>> YAMAMOTO Takashi
>>
>>> hi,
>>>
>>>> On Tue, Nov 29, 2011 at 06:38:27AM +0000, YAMAMOTO Takashi wrote:
>>>>> O->A loaned pages installed on the user address space would have a 
>>>>> different
>>>>> owner than the usual map->entry.uvm_obj.
>>>>> although it was not a problem when you wrote this patch, at least some
>>>>> non-mechanical changes would be required after the recent locking
>>>>> changes in this area.  namely, uvm_map_lock_entry etc now assumes that
>>>>> any pages mapped in a map entry belong to either the entry's amap or
>>>>> underlying object.
>>>>
>>>> ok, I didn't think it would be entirely mechanical.  :-)
>>>>
>>>> what if the O->A loan code also changed the entry's uvm_obj to be the vnode
>>>> that the pages really belong to?  if the loan range in the amap is fully
>>>> populated (which it is in this context) then that shouldn't affect the
>>>> logical contents of the entry, it would just cause anyone locking the entry
>>>> to also lock the vnode.  if the range of the loan is smaller than the
>>>> range of the entry, we could split the entry.  do you think that would 
>>>> work?
>>>
>>> it might work, but i have some concerns:
>>> - entry fragmentation
>>> - the extra uobj reference keeps the file even after unlink
>>>
>>> YAMAMOTO Takashi
>>>
>>>>
>>>> -Chuck


Home | Main Index | Thread Index | Old Index