From owner-freebsd-arch Wed Feb 27 14:20: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 890E237B400 for ; Wed, 27 Feb 2002 14:19:57 -0800 (PST) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.2/8.12.1) with ESMTP id g1RMJkh4057493; Wed, 27 Feb 2002 17:19:46 -0500 (EST) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.2/8.12.1/Submit) id g1RMJjEi057488; Wed, 27 Feb 2002 17:19:45 -0500 (EST) (envelope-from bmilekic) Date: Wed, 27 Feb 2002 17:19:45 -0500 From: Bosko Milekic To: Terry Lambert Cc: Matthew Dillon , Alfred Perlstein , Julian Elischer , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Slab allocator Message-ID: <20020227171945.B46831@unixdaemons.com> References: <200202271926.g1RJQCm29905@apollo.backplane.com> <20020227194256.GR80761@elvis.mu.org> <200202271955.g1RJtAj30178@apollo.backplane.com> <20020227151722.B42681@unixdaemons.com> <3C7D4958.D1B8CD3D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C7D4958.D1B8CD3D@mindspring.com>; from tlambert2@mindspring.com on Wed, Feb 27, 2002 at 01:02:16PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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