On 01.11.2012 12:53, Attilio Rao wrote:
On 10/31/12, Andre Oppermann <an...@freebsd.org> wrote:
On 31.10.2012 19:10, Attilio Rao wrote:
On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao <atti...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
