Date: Mon, 03 Jul 2000 02:03:27 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: David Greenman <dg@root.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 Message-ID: <Pine.BSF.4.21.0007030136320.2431-100000@jehovah.technokratis.com> In-Reply-To: <200007030221.TAA08654@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Jul 2000, David Greenman wrote:
> Yes, malloc is slow for other reasons, but it is especially slow when VM
> pages are freed back to the general pool. Of course it is possible to
> introduce hysteresis in the algorithm such that it doesn't free the pages as
> often, but this (and all the tunables that you proposed) has the negative
> effect of making the allocator more complex. We've tried very hard not to do
> this in the current mbuf allocator, making it nearly as efficient as you can
> get.
* Have you looked at the code I proposed?
http://24.201.62.9/code/mbuf/
(I did some simplification recently, but it's not done yet, so you may
want to look at it).
* Again, I did NOT use malloc()/free() to allocate mbufs. Effectively, I
do something similar to NetBSD's "pool" interface, only much SIMPLER.
* I only proposed ONE additional tunable, and that's the one I mentionned
previously. It has the effect of maintaining speed for those who would
prefer to have it done in a similar way to before.
* I agree with this: - the present allocator is simple
- the present allocator is efficient
So is the new one, but since it introduces a new useful feature,
which has the effect of freeing physical memory when it isn't needed
and when the administrator agrees to do so, it's "simple" and
"efficient" in its own class. By the way, I'm very open to comments
and optimisation suggestions, so if it's not as efficient as possible
right now, then I'd love to hear suggestions pertaining to that, but
that would maintain the new functionality.
> I guess I just don't see the problem on any of the servers that I manage
> (ftp.cdrom.com and ftp.freesoftware.com, for example). There are peaks in
> usage, but they tend to reach the peaks often enough that freeing the pages
> for short term memory gain is just a waste of CPU cycles. Memory is so cheap
> these days that throwing memory at the problem seems to be a very reasonable
> solution, especially when the system clearly needs it during the peaks.
>
> -DG
>
> David Greenman
> Co-founder, The FreeBSD Project - http://www.freebsd.org
> Manufacturer of high-performance Internet servers - http://www.terasolutions.com
> Pave the road of life with opportunities.
I'm getting the unfortunate impression that evolution is being
frowned upon here. Are their other people that frown the proposal out
there to this extent? (i.e. "don't change it if it works") I'd like to
hear some important voices on this issue so that I can decide whether to
just drop this entire thing and forget about it. (in other words, what do
committers and/or core have to say about this?)
Aside from this, I've gotten several other "pro" opinions on this;
some people have even sent suggestions. So I know that I am not the only
one (not by far, in fact) to see an opportunity to benefit from this.
Either way, I know *I* will be using this code in time to come, so I
suppose the question is:
Would you consider committing this code or should I stop posting any
changes I make in the future altogether?
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
bmilekic@technokratis.com * http://www.technokratis.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007030136320.2431-100000>