svn commit: r241798 - in user/andre/tcp_workqueue/sys: kern sys
Andre Oppermann
andre at freebsd.org
Sun Oct 21 11:07:21 UTC 2012
On 21.10.2012 12:21, Gleb Smirnoff wrote:
> On Sun, Oct 21, 2012 at 08:46:16AM +0000, Andre Oppermann wrote:
> A> Author: andre
> A> Date: Sun Oct 21 08:46:15 2012
> A> New Revision: 241798
> A> URL: http://svn.freebsd.org/changeset/base/241798
> A>
> A> Log:
> A> Make sure that global locks have their own CPU cache line in
> A> the .bss section of the kernel and do not end up sharing one
> A> by chance or the place they are defined in.
> A>
> A> Three new macros are added:
> A> MTX_GLOBAL(name) defining the mutex
> A> MTX_GLOBAL_STATIC(name) defining the mutex as static
> A> MTX_GLB(name) accessing the mutex in mtx_lock()
> A>
> A> This makes global locks cache deterministic. Changes to the
> A> .bss layout and ordering due to differences in completely
> A> unrelated parts of the kernel can no longer cause global
> A> locks to share the same CPU cache line.
> A>
> A> This is a proof of concept with only one global lock converted.
> A>
> A> I'm open to suggestions and improvements on the macros and
> A> their naming.
>
> My fault, I have confused you yesterday in our discussion. Actually
> we don't need to embrace declaration into additional struct.
> This code works:
>
> static struct mtx __aligned(CACHE_LINE_SIZE) foo_mtx;
OK, I see. That makes it simpler. I'll still do it with a macro
to do the SMP/UP differentiation.
> When speaking about embracing, I actually meant that we can embrace
> into anonymous struct a mutex and a structures it protects, not a
> mutex only.
In most cases the global locks serve as a serialization point
protecting more than one structure. So it's difficult to chose
where to put it.
> P.S. Before merging such changes to head we need to do some benchmarking
> proving that this isn't a nop.
Ideally it is a nop. It's about being deterministic and preventing
bad things should cache line sharing happen.
--
Andre
More information about the svn-src-user
mailing list