On Wed, Oct 31, 2012 at 6:26 PM, Ian Lepore <free...@damnhippie.dyndns.org> wrote: > On Wed, 2012-10-31 at 18:10 +0000, 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. >> >> Thanks, >> Attilio >> >> > > Doesn't this padding to cache line size only help x86 processors in an > SMP kernel? I was expecting to see some #ifdef SMP so that we don't pay > a big price for no gain in small-memory ARM systems and such. But maybe > I'm misunderstanding the reason for the padding.
I didn't want to do this because this would be meaning that SMP option may become a completely killer for modules/kernel ABI compatibility. Also, if you look at the modified list of locks I don't think they should be too much, I hardly believe ARM UP is going to hurt that much from loosing some padding in tdq structures or callout. 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"