Re: mbuf external buffer reference counters

[Juan Francisco Rodriguez Hervella]

On Thu, 11 Jul 2002, Luigi Rizzo wrote:

> 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.
>

First of all, let me say that Im newbie with these topics, 
I only know a bit about mbufs, but I dont understand how
can an application trim away the refcount if the size is
MCLBYTES = 2040 - sizeof(refcount).

Don't this limit the room which an app. can write ?

Thanks.

JFRH

 
> 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
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message