Date: Wed, 27 Feb 2002 15:17:22 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Alfred Perlstein <bright@mu.org>, Julian Elischer <julian@elischer.org>, Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG Subject: Re: Slab allocator Message-ID: <20020227151722.B42681@unixdaemons.com> In-Reply-To: <200202271955.g1RJtAj30178@apollo.backplane.com>; from dillon@apollo.backplane.com on Wed, Feb 27, 2002 at 11:55:10AM -0800 References: <200202271926.g1RJQCm29905@apollo.backplane.com> <Pine.BSF.4.21.0202271128580.97278-100000@InterJet.elischer.org> <20020227194256.GR80761@elvis.mu.org> <200202271955.g1RJtAj30178@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 27, 2002 at 11:55:10AM -0800, Matthew Dillon wrote: > I don't know what Jeff is doing there but I do seem to recall a > paper from somewhere that indicated it was more efficient to free memory > to the current cpu's per-cpu cache rather then back to the original > cpu's cache because the current cpu's hardware L1/L2 cache likely already > has mastership of the memory. I think Linux does things this way. I seem to recall that in general, if you have a writer <--> reader relationship in your code, that it is better to free back to the originating CPU's cache. That is, if you are the thread doing the freeing and you don't write to the object that you're freeing at all (this is often the case), it is better to free to the originating CPU's cache so as to prevent invalidation. > -Matt > Matthew Dillon > <dillon@backplane.com> -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020227151722.B42681>