Date: Sun, 02 Jul 2000 19:21:19 -0700 From: David Greenman <dg@root.com> To: Bosko Milekic <bmilekic@dsuper.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 Message-ID: <200007030221.TAA08654@implode.root.com> In-Reply-To: Your message of "Thu, 29 Jun 2000 12:01:26 EDT." <Pine.BSF.4.21.0006291154100.3622-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Thu, 29 Jun 2000, David Greenman wrote: > >> We used to do this in FreeBSD, but found that it was a bad idea for >> performance reasons. Freeing and reallocating memory from the high-level >> VM system is quite expensive and the trend in NICs these days is towards >> needing the code to be even faster, not slower. Further, if the 'peak' is >> reached often, then you're probably not really gaining much by freeing >> the memory back to the common pool. > > What was previously done at some point was use the kernel malloc() to > allocate mbufs. As you know, this is a general purpose allocator that has > to first determine what algorithm to use and then store the object > correctly according to its size. This allocator is faster than that > one. This allocator knows that it only has to deal with mbufs and knows > that all of these mbufs are of the same size. 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. 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. 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?200007030221.TAA08654>