Re: "Benchmarking BSD and Linux"

[Venkatesh Srinivas <me@xxxxxxxxxxxxxxxxxxx>]

On Wed, Mar 9, 2011 at 7:02 PM, Ezequiel R. Aguerre <ezeaguerre@gmail.com> wrote:

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

Hi!

There's a lot to reply to here, so I'll save it for tomorrow when I'm more awake :) ; the questions are very good though.

But graphs:
http://leaf.dragonflybsd.org/~vsrinivas/forkpy.png : 2/10 kernel on test29 (Dillon's Phenom II, 64-bit)

http://leaf.dragonflybsd.org/~vsrinivas/forkp.png : yesterday, with the thread and thread caches at 3000.

Scaled the same way.
-- vs