On Wed, Mar 9, 2011 at 7:02 PM, Ezequiel R. Aguerre <[email protected]>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
