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
