[RFC][PATCH 0/13] Per-container dcache management (and a bit more)

[Pavel Emelyanov <xemul@parallels.com>]

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@openvz.org>