Date: Wed, 31 Oct 2012 18:57:37 +0000 From: Attilio Rao <attilio@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: svn-src-head@freebsd.org, Ian Lepore <freebsd@damnhippie.dyndns.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r242402 - in head/sys: kern vm Message-ID: <CAJ-FndCL7bpkbfaaR%2BaYQAxEBDmgip0QbrE5JhwnbTicSraz9g@mail.gmail.com> In-Reply-To: <CAJ-VmokqEFX4wQYh-ojo3kcWUPj5L-V_k0Nj-u3sQByVypkDFw@mail.gmail.com> References: <201210311807.q9VI7IcX000993@svn.freebsd.org> <CAJ-FndDRkBS57e9mzZoJWX5ugJ0KBGxhMSO50KB8Wm8MFudjCA@mail.gmail.com> <1351707964.1120.97.camel@revolution.hippie.lan> <CAJ-FndC7QwpNAjzQTumqTY6Sj_RszXPwc0pbHv2-pRGMqbw0ww@mail.gmail.com> <CAJ-VmokqEFX4wQYh-ojo3kcWUPj5L-V_k0Nj-u3sQByVypkDFw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/31/12, Adrian Chadd <adrian@freebsd.org> wrote: > On 31 October 2012 11:33, Attilio Rao <attilio@freebsd.org> wrote: > >>> 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. > > Right, but you didn't make it configurable for us embedded peeps who > still care about memory usage. How is this possible without breaking the module/kernel ABI? >> 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. > > There's a few million more embedded MIPS boards out there with > 16mb/32mb of RAM than target PCs for FreeBSD. > > Would you mind making the padding part configurable and just default > it to "do the padding" ? > That way for the atheros MIPS builds I can turn it off and save on the > memory overhead. This means that we will need to put a black cross on the compatibility between modules and kernel very likely. Changable size locks based on the options are a very bad idea and if they change the size based on the availability of SMP or a main option like that (ie. differently from debugging options) are even a worse idea. Besides the mtx_padalign mutexes should be not be used often in general, that's why I ask people to justify their introduction every time. And as last point, please consider that right now the locks converted are the same that were before, so there is no loss for mips or similar. All that assuming you can actually prove a real performance loss even in the new cases. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndCL7bpkbfaaR%2BaYQAxEBDmgip0QbrE5JhwnbTicSraz9g>