Date: Tue, 24 Jun 2003 20:34:31 +0100 From: Bruce M Simpson <bms@spc.org> To: freebsd-hackers@freebsd.org Cc: jmallett@freebsd.org Subject: Optimizing mutex alignment viz cache line access Message-ID: <20030624193431.GW9463@spc.org>
next in thread | raw e-mail | index | archive | help
--4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, There's an idea for optimizing cache line access through object alignment tricks in the attached mail. Feedback would be valu[able|ed]. BMS --4Epv4kl9IRBfg3rk Content-Type: message/rfc822 Content-Disposition: inline Date: Tue, 24 Jun 2003 17:45:42 +0100 From: Bruce M Simpson <bms@spc.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: David Schultz <das@freebsd.org> Subject: Re: Page Coloring Defines in vm_page.h Message-ID: <20030624164542.GU31354@spc.org> References: <20030624111942.GO31354@spc.org> <20030624131748.GB58305@HAL9000.homeunix.com> <20030624133813.GR31354@spc.org> <200306241625.h5OGPhE2094185@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306241625.h5OGPhE2094185@apollo.backplane.com> User-Agent: Mutt/1.4.1i On Tue, Jun 24, 2003 at 09:25:43AM -0700, Matthew Dillon wrote: [..] > the optimized values are going to be so small (probably not even > measureable) that it isn't worth doing. Ok. Tweaking page coloring viz other architectures is a bikeshed. In the absence of numbers it was necessary to test the idea. Moving swiftly on... > If you want to find something to optimize, then cache-line alignment > of data structures and ensuring that multiple data structures > (such as mutexes) which are potentially used by different cpus do > not share the same cache line is going to reap far greater benefits > then messing around with the page coloring algorithm. Now *that* is an interesting problem, and extremely difficult to crack, at least for the entire kernel. It would require a map of every instance of such a shared structure in terms of its location within each page. In the case of dynamically-allocated structures such as the softc for a character device, it is even harder to deterministically calculate the location of a mutex member of such a softc in memory. Correct me if I'm wrong here? Would the workaround, then, not be to modify the mtx_*() set of functions to use a zone allocator, whose allocation function could then be tuned to allocate the lock structure which is frobbed by the atomic_*() functions on separate cache lines? BMS --4Epv4kl9IRBfg3rk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030624193431.GW9463>