Date: Mon, 17 Feb 2003 22:13:49 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <20030217221349.A67942@unixdaemons.com> In-Reply-To: <Pine.BSF.4.21.0302171733020.16142-100000@InterJet.elischer.org>; from julian@elischer.org on Mon, Feb 17, 2003 at 05:38:27PM -0800 References: <20030217192418.A67144@unixdaemons.com> <Pine.BSF.4.21.0302171733020.16142-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 17, 2003 at 05:38:27PM -0800, Julian Elischer wrote: > On Mon, 17 Feb 2003, Bosko Milekic wrote: > [...] > Bosko, If I have one NIC bound to one CPU (a future capability say,) > and another bound to a second, and there is a stream of packets fron > NIC1 to NIC2 (we are routing) at (say) 30,000 packets per second, > what is the path by which those 30,000 packets make their way from > CPU2's cache of mbufs, back to CPU1 to be used again? (each second). > We'll imagine there are no packets going the other way. (maybe they take > a different route). If the mbufs are allocated from CPU1's cache then they'll most likely be freed back to CPU1's cache. The way it works is that the mbuf is freed back to its bucket and so to whichever cache the bucket is sitting in. Most likely the bucket will not have migrated caches so you're going to be using CPU1's cache in this scenario, since that's the cache you're allocating from. This is probably not ideal when you do something like bind the NIC to a CPU but it is better than having the freing thread free to its own cache, in which case you'd have a serious debalancing of caches going on. I'm not sure how performance would be impacted either way, but I guess I can't say until we actually bind the NICs each to their own CPUs and measure. -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org "If we open a quarrel between the past and the present, we shall find that we have lost the future." 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?20030217221349.A67942>