Date: Sat, 29 Jun 2002 23:09:27 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629230927.A78684@iguana.icir.org> In-Reply-To: <20020629190844.A54115@unixdaemons.com>; from bmilekic@unixdaemons.com on Sat, Jun 29, 2002 at 07:08:44PM -0400 References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 29, 2002 at 07:08:44PM -0400, Bosko Milekic wrote: ... > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] I have to say i did the tests on a -stable uniprocessor box, so the locking costs are almost negligible there, and all the gain that i measured comes from not having to do the bookkeeping. On -current, I have no idea. But i wonder, which CPU gets to serve the interrupt handler (or equivalently, the polling loop) ? Is it picked up at random, or it is statically assigned to devices or irq lines or what ? Because the per-CPU allocation may or may not be a good idea depending on the above -- e.g. if the receiving and transmitting interrupt handler end up on different CPUs then the cache becomes totally useless (and i am not mentioning those clusters freed in the protocol stack because that still runs under Giant and it will take a while before it can be parallelised). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020629230927.A78684>