Date: Wed, 27 Feb 2002 17:19:45 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@mu.org>, Julian Elischer <julian@elischer.org>, Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG Subject: Re: Slab allocator Message-ID: <20020227171945.B46831@unixdaemons.com> In-Reply-To: <3C7D4958.D1B8CD3D@mindspring.com>; from tlambert2@mindspring.com on Wed, Feb 27, 2002 at 01:02:16PM -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> <20020227151722.B42681@unixdaemons.com> <3C7D4958.D1B8CD3D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 27, 2002 at 01:02:16PM -0800, Terry Lambert wrote: > Bosko Milekic wrote: > > 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. > > This is true, but since it's an exceptional case, you can > use a seperate queue with a lock, rather than interposing > a lock into the global space. This also limits the contention > window considerably, and eliminates the locking in the common > case. > > As far as invalidation is concerned, you are already screwed > on cache lines when you passed it off to the other CPU. The > migration events need to be exceptional, rather than common. > That they are common now is a bug in the scheduler. It is > very unlikely, unless you rewrite all of the code, that you > are going to avoid an mbuf allocated at interrupt on one CPU > having the inp->ip_vhl modified on another (for example), if > the protocol processing moves. OK, since you obviously know what you're talking about, how about you sit down and produce some patches for Jeff? I think he would appreciate it very much, instead of the generalizations and "you should not do this, but do X" abstractions. > -- Terry -- 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?20020227171945.B46831>