From owner-freebsd-hackers Mon Jul 3 0:22:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 5C06437B7D0 for ; Mon, 3 Jul 2000 00:22:32 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FX30040XY2B6P@field.videotron.net> for freebsd-hackers@FreeBSD.ORG; Mon, 3 Jul 2000 02:01:23 -0400 (EDT) Date: Mon, 03 Jul 2000 02:03:27 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf re-write(s), v 0.1 In-reply-to: <200007030221.TAA08654@implode.root.com> X-Sender: bmilekic@jehovah.technokratis.com To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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