Re: "Benchmarking BSD and Linux"

["Ezequiel R. Aguerre" <ezeaguerre@xxxxxxxxx>]

Hi! First time writing here :-)

I would love to see the curve. What do you mean by "much flatter", do
you mean that it looks like O(1) instead of O(n) (or something like
that)?

And I can't understand why caching all those data structures are not a
good idea in general.

Free up memory for other purposes: I think it should be fairly easy to
free up that memory.
 * A lot of those structures probably don't have sensitive
information, so no need to zero fill (??)
 * And if you do need to zero fill pages you could (maybe) have a
"cache" of zero filled pages, so you could reclaim other pages and
zero fill them as a background process. Yes... it is other cache...
but other operating systems have used this technique before, and I
think it worked pretty well.
 * By using something like a SLAB allocator you could probably just
free entire pages of memory in one simple and quick operation when you
do need to reclaim memory from the caches.

KVM fragmentation: Well, how much? is it really important? and if it
is... is it worse that the lack of the caches?

Aren't the memory management subsystems based on SLAB allocator
basically a bunch of caches? For example, Linux, FreeBSD, Solaris...
all of them use a SLAB allocator, and all of them have good
performance. I don't really know MUCH about their internal workings,
but I can say that Linux even uses the SLAB for the kernel general
purpose allocator (kmalloc). Regarding fragmentation... I think that
using extensively the SLAB, in fact, reduces fragmentation.
And this reminds me that FreeBSD introduced the slab allocator in
FreeBSD 5.0 (the one benchmarked is the 5.1).

So, I can't understand why caching those data structures are a bad
idea for a production system.

Have a nice day! :-)

--
Ezequiel R. Aguerre