From owner-freebsd-hackers Mon Jul 3 1:31:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B3E6137B895 for ; Mon, 3 Jul 2000 01:31:26 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id BAA09516; Mon, 3 Jul 2000 01:20:15 -0700 (PDT) Message-Id: <200007030820.BAA09516@implode.root.com> To: Bosko Milekic Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 In-reply-to: Your message of "Mon, 03 Jul 2000 02:03:27 EDT." From: David Greenman Reply-To: dg@root.com Date: Mon, 03 Jul 2000 01:20:15 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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? What I'm doing is challenging your assertions that spending CPU cycles to save memory in the networking code is the right thing to do. I'm further saying that I have direct experiance in this area since I'm one of the primary people in FreeBSD's history that have spent major amounts of effort in improving its performance, especially in the networking area. We (actually John Dyson and I) made a conscience decision to waste memory in trade for performance and if we (FreeBSD developers in general) decide to go in the opposite direction, then it sure ought to be well thought out and have solid reasoning behind it. In our discussions so far, I haven't yet seen any real numbers to back up the claims. What is needed is: 1) Some numbers that show that the memory wastage is significant - and I'm talking about multiple megabytes at least. If its not 'significant' by that definition (and in my experiance it isn't), than I'd like to hear why you think much smaller numbers are significant. 2) I'd like to see some more numbers that show that the additional CPU wastage is very minimal (say less than 1% of the total amount of time spent doing the allocs/frees). I'm not trying to 'frown upon evolution', unless the particular form of evolution is to make the software worse than it was. I *can* be convinced that your proposed changes are a good thing and I'm asking you to step up to the plate and prove it. -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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message