Date: Tue, 2 Jul 2002 10:12:22 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: net@FreeBSD.ORG Subject: Re: Mbuf allocator performance (was Should we keep a cache of mbuf+cluster ready for use ?) Message-ID: <20020702101222.C7966@iguana.icir.org> In-Reply-To: <20020702130135.A17370@unixdaemons.com>; from bmilekic@unixdaemons.com on Tue, Jul 02, 2002 at 01:01:35PM -0400 References: <20020702001050.B2250@iguana.icir.org> <20020702080423.A69693@unixdaemons.com> <20020702090354.A78632@unixdaemons.com> <20020702085640.B5854@iguana.icir.org> <20020702130135.A17370@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 02, 2002 at 01:01:35PM -0400, Bosko Milekic wrote: ... > The reason I said "seemingly" is because of the fact that I don't > think that it is your "grouping" of both clusters and mbufs that > specifically causes the perf. increase to the extent you showed with > your tests. What you're doing in the code you posted is also avoiding could be, i don't know... but this is exactly why we both agree that we better provide an interface so that we can work out in parallel improvements in the driver and improvements in the mbuf code. > 1) Remove the malloc() for external ref. count allocations; instead, > store the ref. count at the end of the cluster like I did when I took this seems to violate one of your points about cache pollution! but i am totally neutral on this one. > 2) Introduce an interface that will allocate and free: > (i) an mbuf with a cluster attached to it; > (ii) an M_PKTHDR mbuf with a cluster attached to it; > However, this interface would wrap the appropriate alloc/free > routines, although it would take care to not drop the allocation > lock between the allocations. I don't suspect this to be too > difficult to do. fine with me. > It is not safe if you use it too often. The allocator was designed to > allocate, it HAS caches, it doesn't need for everyone under the Sun to > start keeping their own caches on top of that. which is what happens when they realise they can do things faster :) > 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. 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?20020702101222.C7966>