Hi. According to the "release early, release often" strategy :) I'm glad to propose this scratch implementation of what I was talking about at the LSF - the way to limit the dcache grow for both containerized and not systems (the set applies to 2.6.38). The first 5 patches are preparations for this, descriptive (I hope) comments are inside them. The general idea of this set is -- make the dentries subtrees be limited in size and shrink them as they hit the configured limit. Why subtrees? Because this lets having the [dentry -> group] reference without the reference count, letting the [dentry -> parent] one handle this. Why limited? For containers the answer is simple -- a container should not be allowed to consume too much of the host memory. For non-containerized systems the answer is -- to protect the kernel from the non-privileged attacks on the dcache memory like the "while :; do mkdir x; cd x; done" one and similar. What isn't in this patch yet, but should be done after the discussion * API. I haven't managed to invent any perfect solution, and would really like to have it discussed. In order to be able to play with it the ioctls + proc for listing are proposed. * New mounts management. Right now if you mount some new FS to a dentry which belongs to some managed set (I named it "mob" in this patchset), the new mount is managed with the system settings. This is not OK, the new mount should be managed with the settings of the mountpoint's mob. * Elegant shrink_dcache_memory on global memory shortage. By now the code walks the mobs and shinks some equal amount of dentries from them. Better shrinking policy can and probably should be implemented. Signed-off-by: Pavel Emelyanov <xemul@xxxxxxxxxx> -- 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
