svn commit: r242402 - in head/sys: kern vm

[Attilio Rao]

On 11/1/12, Andre Oppermann <andre at freebsd.org> wrote:
> On 01.11.2012 12:53, Attilio Rao wrote:
>> On 10/31/12, Andre Oppermann <andre at freebsd.org> wrote:
>>> On 31.10.2012 19:10, Attilio Rao wrote:
>>>> On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao <attilio at freebsd.org>
>>>> wrote:
>>>>> Author: attilio
>>>>> Date: Wed Oct 31 18:07:18 2012
>>>>> New Revision: 242402
>>>>> URL: http://svn.freebsd.org/changeset/base/242402
>>>>>
>>>>> Log:
>>>>>     Rework the known mutexes to benefit about staying on their own
>>>>>     cache line in order to avoid manual frobbing but using
>>>>>     struct mtx_padalign.
>>>>
>>>> Interested developers can now dig and look for other mutexes to
>>>> convert and just do it.
>>>> Please, however, try to enclose a description about the benchmark
>>>> which lead you believe the necessity to pad the mutex and possibly
>>>> some numbers, in particular when the lock belongs to structures or the
>>>> ABI itself.
>>>>
>>>> Next steps involve porting the same mtx(9) changes to rwlock(9) and
>>>> port pvh global pmap lock to rwlock_padalign.
>>>
>>> I'd say for an rwlock you can make it unconditional.  The very purpose
>>> of it is to be aquired by multiple CPU's causing cache line dirtying
>>> for every concurrent reader.  Rwlocks are only ever used because
>>> multiple
>>> concurrent readers are expected.
>>
>> I thought about it, but I think the same arguments as for mutexes
>> remains.
>> The real problem is that having default rwlocks pad-aligned will put
>> showstoppers for their usage in sensitive structures. For example, I
>> have plans to use them in vm_object at some point to replace
>> VM_OBJECT_LOCK and I do want to avoid the extra-bloat for such
>> structures.
>>
>> Also, please keep in mind that there is no direct relation between
>> "read acquisition" and "high contention" with the latter being the
>> real reason for having pad-aligned locks.
>
> I do not agree.  If there is no contention then there is no need for
> a rwlock, a normal mutex would be sufficient.  A rwlock is used when
> multiple concurrent readers are expected.  Each read lock and unlock
> dirties the cache line for all other CPU's.
>
> Please note that I don't want to prevent you from doing the work all
> over for rwlocks.  It's just that the use case for a non-padded rwlock
> is very narrow.

So here is the patch for adding the decoupling infrastructure to
rwlock and add the padalign type:
http://www.freebsd.org/~attilio/rwlock_decoupled_padalign.patch

I've tested by converting some rwlocks in the system and everything
looks good to me.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein