Date: Sat, 29 Jun 2002 19:08:44 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Jeffrey Hsu <hsu@FreeBSD.ORG> Cc: Luigi Rizzo <rizzo@icir.org>, net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629190844.A54115@unixdaemons.com> In-Reply-To: <0GYH00JJCOL3HO@mta7.pltn13.pbi.net>; from hsu@FreeBSD.ORG on Sat, Jun 29, 2002 at 03:46:31PM -0700 References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Regards, -- 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?20020629190844.A54115>