Date: Thu, 4 Jul 2002 13:38:35 +0300 (EEST) From: Iasen Kostov <ikostov@otel.net> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Luigi Rizzo <rizzo@icir.org>, <net@FreeBSD.ORG> Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020704131637.L52213-100000@shadowhand.OTEL.net> In-Reply-To: <20020702134653.A17641@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Jul 2002, Bosko Milekic wrote: ... <cut> > > > Here's what happens: > > > > > > Consumers A and B each keep their own "pools" of mbufs+clusters. > > > ... > > > > look, this is exactly what happens with network interfaces. If > > they fail to allocate a new mbuf, they keep recycling > > the one they have from the receive queue instead of freeing it. > > Yes, but that's because they _need_ an mbuf, they can't get one, so > they re-use one. If you build a local pool in which you store UNUSED > mbufs, with no real idea of when they'll be used - only with the > assumption/hope that you'll use them "soon" - and if you do this in > several different places in the kernel, you are bound to hit brokeness > under heavy load, when you need to block from other locations to get > your network buffers and cannot do that because someone else is > "assuming" they'll need a bunch "sometime soon." But if it is tunable ? And if it can be tuned for specific task that the signle machine do ? As example you can set something like "keep_buffers" for parts of system that you need to work faster in your single case. It could be a kernel variable, #ifdef or both. > > This is why we have per-CPU caches and a global cache. The per-CPU > caches load themselves accordingly, and they'll give you what you're > looking for when you need it, from a cache. Sure, the caches are a > tad bit more expensive to twiddle, but this is the compromise we make > in order to ensure that the system knows about our caches and is able > to cope even under heavy load. > > > cheers > > luigi > > -- > 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 > 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?20020704131637.L52213-100000>