Date: Thu, 6 Jul 2000 11:09:08 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Greenman <dg@root.com> Cc: Bosko Milekic <bmilekic@dsuper.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 Message-ID: <200007061809.LAA94737@apollo.backplane.com> References: <200007030221.TAA08654@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:...
:> 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
Our userland malloc() has been quite successful using MADV_FREE to
'release' free pages without actually releasing them. The system
would reclaim the pages only when it needed them.
We might be able to do something similar for our kernelland malloc,
though at the moment I don't see much of a point (it seems fast enough
to me and I don't see much wasteage either).
-Matt
Matthew Dillon
<dillon@backplane.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?200007061809.LAA94737>