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

[Andre Oppermann]

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.

-- 
Andre