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

[Attilio Rao]

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.

Attilio


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