Date: Sun, 21 Oct 2012 13:07:11 +0200 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r241798 - in user/andre/tcp_workqueue/sys: kern sys Message-ID: <5083D75F.6050603@freebsd.org> In-Reply-To: <20121021102155.GA64905@FreeBSD.org> References: <201210210846.q9L8kGX7029653@svn.freebsd.org> <20121021102155.GA64905@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5083D75F.6050603>