Date: Wed, 27 Feb 2002 13:02:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.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: <3C7D4958.D1B8CD3D@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Terry 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?3C7D4958.D1B8CD3D>