Date: Thu, 11 Jul 2002 13:38:02 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbuf external buffer reference counters Message-ID: <20020711133802.A31827@iguana.icir.org> In-Reply-To: <20020711162026.A18717@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, Jul 11, 2002 at 04:20:26PM -0400 References: <20020711162026.A18717@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, certainly removing the malloc will improve performance a lot. As I already mentioned to Bosko, in principle the available area in ext.buffers is irrelevant, and i do not believe this will break anything (and if it does, it will be easy to fix in the kernel), but some applications might decide to do writes in multiple of 1K and trimming away the refcount area might easily result in suboptimal allocation of storage within the kernel. I'd probably try to use the same technique as -stable (i.e. have a separate array for all refcounts), if that is not too bad from other points of view. cheers luigi On Thu, Jul 11, 2002 at 04:20:26PM -0400, Bosko Milekic wrote: > > Hi, > > Right now, in -CURRENT, there is this hack that I introduced that > basically just allocates a ref. counter for external buffers attached > to mbufs with malloc(9). What this means is that if you do something > like allocate an mbuf and then a cluster, there's a malloc() call that > is made to allocate a small (usually 4-byte) reference counter for it. > > That sucks, and even -STABLE doesn't do this. I changed it this way > a long time ago for simplicity's sake and since then I've been meaning > to do something better here. The idea was, for mbuf CLUSTERS, to > stash the counter at the end of the 2K buffer area, and to make > MCLBYTES = 2048 - sizeof(refcount), which should be more than enough, > theoretically, for all cluster users. This is by far the easiest > solution (I had it implemented about 10 months ago) and it worked > great. > > The purpose of this Email is to find out if anyone has concrete > information on why this wouldn't work (if they think it wouldn't). > So, if someone has an example of some broken code somewhere that > wouldn't like this, please point it out to me now before I go off and > do this again and commit it. > > Thanks, > -- > 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?20020711133802.A31827>