RFC Per-container dcache management (and a bit more)
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest13 patches 9 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/13 | vfs: Lighten r/o rename_lock lockersfs/ include/ | +29 | 0 replies | |
| 2/13 | vfs: Factor out rename_lock lockingfs/ | +6 | 0 replies | |
| 3/13 | vfs: Make the rename_lock per-sbdrivers/ fs/ fs/ +5 more | +44 | 0 replies | |
| 4/13 | vfs: Factor out tree (of four) shrinkers codefs/ | +130 | 0 replies | |
| 5/13 | vfs: Make dentry LRU list globalfs/ fs/ include/ | +15 | 0 replies | |
| 6/13 | vfs: Turn the nr_dentry into percpu_counterfs/ include/ | +6 | 0 replies | |
| 7/13 | vfs: Limit the number of dentries globallyfs/ | +33 | 0 replies | |
| 8/13 | vfs: Introduce the dentry mobsfs/ include/ | +33 | 1 reply | |
| 9/13 | vfs: More than one mob managementfs/ include/ | +186 | 0 replies | |
| 10/13 | vfs: Routnes for setting mob size and getting statsfs/ include/ | +37 | 0 replies | |
| 11/13 | vfs: Make shrink_dcache_memory prune dcache from all mobsfs/ include/ | +35 | 0 replies | |
| 12/13 | vfs: Mobs creation and mgmt APIfs/ include/ | +12 | 0 replies | |
| 13/13 | vfs: Dentry mobs listing in procfs/ fs/ include/ | +63 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC][PATCH 0/13] Per-container dcache management (and a bit more)
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.