On 11/1/12, Andre Oppermann <an...@freebsd.org> wrote: > 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.
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 _______________________________________________ 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"
