> > Hello Yiftach, Dormando and everyone, > > I work with Eyal exactly on that: OSes that get and lose physical memory at > runtime. > We are interested in memcached because it is an important cloud benchmark > which stresses the memory. > > I think the way memcached deals with changes in the value size distribution > has to do with dynamic memory. > If memchaced caches many small objects, many slabs for small-size items are > allocated. If then the distribution changes, and suddenly all objects are > large-sized, > then at some point small-size slabs need to be freed, or at least cleared and > replaced by large-size slabs. If this is indeed what happens, we could take > advantage > of the point in time when a slab is freed or cleared, and reclaim the slab > (assuming the memory was not preallocated). > I found a comment saying /* so slab size changer can tell later if item is > already free or not */", but I could not find the implementation of such a > mechanism. > > Do you find this a reasonable approach?
You're making some assumptions between the LRU and slab allocation. A slab will be full of completely random allocations, ejecting memory to free it up will lose a bunch of items. It also doesn't do what you suggest, not natively. Before 1.4.11 slab memory allocations were static. If you loaded small items, then large items, your large items would have no memory. http://code.google.com/p/memcached/wiki/ReleaseNotes1411 If you look at how the slab mover is implemented, you could inject yourself into the slab mover, and instead of moving a slab between one class and another, free it once the items are cleared. It is, as I said, not something you want to do all willy-nilly. Preserving the items in the slab page you intend to move requires a lot more careful work than I was willing to do at the time. It might be too slow as well.
