svn commit: r242402 - in head/sys: kern vm
Attilio Rao
attilio at freebsd.org
Wed Oct 31 18:33:53 UTC 2012
On Wed, Oct 31, 2012 at 6:26 PM, Ian Lepore
<freebsd at 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 <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.
>>
>> 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
More information about the svn-src-head
mailing list