|| ||Pavel Emelyanov <email@example.com> |
|| ||Hugh Dickins <firstname.lastname@example.org>, Nick Piggin <email@example.com>,
Andrea Arcangeli <firstname.lastname@example.org>,
Rik van Riel <email@example.com>,
Dave Hansen <firstname.lastname@example.org>,
|| ||[RFC][PATCH 0/13] Per-container dcache management (and a bit more) |
|| ||Tue, 03 May 2011 16:14:37 +0400|
|| ||linux-fsdevel <email@example.com>|
|| ||Article, Thread
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
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
* 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 <firstname.lastname@example.org>
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html