On Mon, Aug 15, 2011 at 10:12:06AM +0300, Pekka Enberg wrote: > On Sun, Aug 14, 2011 at 6:13 PM, Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: > > This patch lays the foundation for us to limit the dcache size. > > Each super block can have only a maximum amount of dentries under its > > sub-tree. Allocation fails if we we're over limit and the cache > > can't be pruned to free up space for the newcomers. ..... > We track the total number of objects in mm/slub.c when > CONFIG_SLUB_DEBUG is enabled (look for n->total_objects in the code). > Have you considered extending that for this purpose? That's usage for the entire slab, though, and we don't have a dentry slab per superblock so I don't think that helps us. And with slab merging, I think that even if we did have a slab per superblock, they'd end up in the same slab context anyway, right? Ideally what we need is a slab, LRU and shrinkers all rolled into a single infrastructure handle so we can simply set them up per object, per context etc and not have to re-invent the wheel for every single slab cache/LRU/shrinker setup we have in the kernel. I've got a rough node-aware generic LRU/shrinker infrastructure prototype that is generic enough for most of the existing slab caches with shrinkers, but I haven't looked at what is needed to integrate it with the slab cache code. That's mainly because I don't like the idea of having to implement the same thing 3 times in 3 different ways and debug them all before anyone would consider it for inclusion in the kernel. Once I've sorted out the select_parent() use-the-LRU-for-disposal abuse and have a patch set that survives a 'rm -rf *' operation, maybe we can then talk about what is needed to integrate stuff into the slab caches.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
