Date: Sat, 16 Jun 2001 12:29:00 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Alfred Perlstein <bright@rush.net> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-current@FreeBSD.ORG, terry@FreeBSD.ORG, rwatson@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: New Mbuf Allocator (some graphs) Message-ID: <20010616122900.A6914@technokratis.com> In-Reply-To: <20010616031121.K1832@superconductor.rush.net>; from bright@rush.net on Sat, Jun 16, 2001 at 03:11:21AM -0400 References: <20010615185421.A1179@technokratis.com> <20010615183255.C68883@prism.flugsvamp.com> <20010615194459.A1549@technokratis.com> <20010615235605.E68883@prism.flugsvamp.com> <20010616031121.K1832@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 16, 2001 at 03:11:21AM -0400, Alfred Perlstein wrote:
> It would be better if we could allocate/free clusters+mbufs+refcounts
> under a single lock. It would simplify the API and save a boatload
> of cycles and i-cache by avoiding the mutex operations.
>
> Not that I object to the current code, I'm just wondering when this
> important optimization is going to be made, or that the interface
> will settle down enough so that I can get started on it.
Well, as I've mentionned to you previously, I don't think this will
be an optimization. The mb_alloc code already shares the same lock for both
mbufs and clusters and, as for counters, it is not efficient to allocate
them from the mb_alloc allocation routines (due to their extremely small
size, we would consume double the memory to manage them). So what I've
done in mb_alloc is have the counters malloc()ed. However, as I've mentionned,
and as I've already (although quickly) implemented in order to perform testing,
I'm going to change it so that for clusters, the space for the reference counter
will actually be located at the end of the unused portion of the cluster. As
for the other types of buffers, I'll have to sit and think about it some
more but there are obvious solutions that are more optimal than the present
malloc() scheme which I've put in for simplicity purposes.
In any case, I don't *think* it will be an actual optimization (because the
lists are now per-CPU and there doesn't seem to be a genuine reason for it), but
if, once the dust settles, you can figure out a way to easily implement it
without pessimizing any of the code to do it, then it's certainly worth a shot.
After all, you were right about some of these not-so-obvious things before. :-)
I think that once we have the new code in, and once I fix the little
malloc() thing, that we should really focus on the remainder of the net code
simply because I want to see Giant get lifted from this area.
> --
> -Alfred Perlstein [alfred@freebsd.org]
> Instead of asking why a piece of software is using "1970s technology,"
> start asking why software is ignoring 30 years of accumulated wisdom.
Regards,
--
Bosko Milekic
bmilekic@technokratis.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010616122900.A6914>