Date: Sat, 29 Jun 2002 19:29:29 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Alfred Perlstein <bright@mu.org> Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, Luigi Rizzo <rizzo@icir.org>, net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629192929.A58120@unixdaemons.com> In-Reply-To: <20020629231120.GO97638@elvis.mu.org>; from bright@mu.org on Sat, Jun 29, 2002 at 04:11:20PM -0700 References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com> <20020629231120.GO97638@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 29, 2002 at 04:11:20PM -0700, Alfred Perlstein wrote: > If the pool is per-device-softc then it doesn't need locks and will > be a lot more efficient than even grabbing from the per cpu pool. We have an allocator that does per-CPU allocations, we don't need to add additional layers of caches on top of that. The only thing you would save would be avoiding having to lock and unlock a cache. Since the lock is a per-CPU lock (because the caches are per-CPU), the contention on it is very low unless, of course, you get pre-empted somewhere during the allocation and then migrate CPUs; but this is not that likely to happen, really (not right now, anyway). > Also, (/me does a little dance) TOLD YOU SO ABOUT THE ALLOCATION CODE! Huh? If you're referring to the grouped mbuf + cluster allocation interface, I haven't yet admitted that it is worth it. I specifically said that it depends on how the architecture deals with bus-locked instructions and cache use. In other words, it depends on how expensive a unlock+relock operation is when we're dealing with the same lock. If we're allowed to go to the cache during the bus-locked unlock+relock ops, then we should be getting cache hits so strictly speaking, them being there is not such a big deal. But again, I have no idea what happens with cache interactions during a bus-locked instruction. > hah! :) > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org 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?20020629192929.A58120>