Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 Nov 2012 15:29:41 +0100
From:      Andre Oppermann <andre@freebsd.org>
To:        attilio@FreeBSD.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r242402 - in head/sys: kern vm
Message-ID:  <50928755.6070401@freebsd.org>
In-Reply-To: <CAJ-FndD6FVj9X-ZDOLn4yMMv_5tT7EZj0ZCu7ADy5ho_7%2BK2uw@mail.gmail.com>
References:  <201210311807.q9VI7IcX000993@svn.freebsd.org> <CAJ-FndDRkBS57e9mzZoJWX5ugJ0KBGxhMSO50KB8Wm8MFudjCA@mail.gmail.com> <50918FEC.3070602@freebsd.org> <CAJ-FndD6FVj9X-ZDOLn4yMMv_5tT7EZj0ZCu7ADy5ho_7%2BK2uw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01.11.2012 12:53, Attilio Rao wrote:
> On 10/31/12, Andre Oppermann <andre@freebsd.org> wrote:
>> On 31.10.2012 19:10, Attilio Rao wrote:
>>> On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao <attilio@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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50928755.6070401>