Date: Sat, 29 Jun 2002 16:11:20 -0700 From: Alfred Perlstein <bright@mu.org> To: Bosko Milekic <bmilekic@unixdaemons.com> 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: <20020629231120.GO97638@elvis.mu.org> In-Reply-To: <20020629190844.A54115@unixdaemons.com> 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
* Bosko Milekic <bmilekic@unixdaemons.com> [020629 16:09] wrote: > > On Sat, Jun 29, 2002 at 03:46:31PM -0700, Jeffrey Hsu wrote: > > So, what you want is something like a > > MGETHCL(m, how, type) > > MHCLFREE(m) > > interface which first looks in a combined freelist before the individual > > mbuf and cluster freelists. I think it's a good idea. > > 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. [*] > > In -CURRENT right now, clusters and mbufs are allocated from > different per-CPU cache lists but they _share_ per-CPU > locks, therefore this is entirely do-able. Having yet another cache > that holds linked cluster + mbufs would really complicate allocations. > > [*] Admittedly, Alfred was pushing for exactly this not long ago, but > I just didn't feel like doing it because I felt that there are better > things to worry about than a little unlock + relock, when we're just > dropping and re-acquiring the exact same lock, I don't see it as too > big of a deal. However, I'm really not sure as to how smart > architectures like Intel are with bus-locked instructions and data > cache use. If they're stupid about it (i.e., if they don't look at > caches during a bus-locked cycle), then it could be worth it to avoid > that extra unlock/relock between allocations. If they're fairly smart > about it, it's really not worth it. > > Also, I should mention that in his original message, Luigi mentions > that MGETHDR and MCLGET are rather long macros, but in -CURRENT they > are functions so there is not really much added code cache pollution. Heh... :) 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. Also, (/me does a little dance) TOLD YOU SO ABOUT THE ALLOCATION CODE! 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020629231120.GO97638>