>> Again I don't think the >> objective is a perfect accounting but just something that happen to >> works better, if one wants perfect accounting of the memory and bytes >> utilized by the on-disk image there are other types of virt available. > > IOWs, they want per-container resource limits. I'd suggest that any > solution along these lines needs to use existing infrastructure (i.e > cgroups) to control the resource usage of a given container... The problem is that dcache memory is not tied to ANY group of tasks, while the cgroups engine's idea is to control the resource consumption of a task group. Thus the cgroup engine is not suitable for this. Besides, the dcache is likely to get shared between several tasks (task groups) and thus we'll face the same problems we're now having the the memory controller. However, I'm open for discussion if you propose some way for extending it on resources, that are not directly related to tasks. > FYI, the way I am trying to solve this problem is as follows: > > 1. Encode the reclaim dependency in the VFS cache memory > reclaim implementation. > > -> per-sb shrinker implementation > -> per-sb LRU lists > -> per-sb locking > -> binds dentry, inode and filesystem inode > cache reclaim together > -> allows LRU scalability to be adressed > indepenedently at a future time > -> patches already out for review > > 2. provide global cache limiting at inode/dentry allocation > time > > -> calls per-sb shrinker to free inodes on same sb > -> can be done asynchrounously > -> no new locking/lifecycle issues > -> no cross-sb reference/locking issues For 1. and 2. do s/per-sb/per-mob/ So how does it differ from the mobs concept? > 3. add cache size limiting to cgroup infrastructure > -> just another level of abstraction to existing > infrastructure > -> ties in with existing resource limiting > mechanisms in the kernel > > Basically the concept of "mobs" ends up being subsumed by cgroups, Nope, the mobs are independent from cgroups. > but only at the LRU level and has no hooks into the dentry > cache heirarchy at all. What do you mean by this? The mob is tightly coupled with the dentry cache! > i.e. reclaim works just like it does now, but it is simply container-aware. No it is not - it just breaks the global dentry LRU into smaller ones. No containers at that point at all. > We're already having to solve > these issues for cgroup-aware dirty page writeback (i.e. making the > bdi-flusher infrastructure cgroup aware), so this is not as big a > leap as you might think. It also avoids the need for a one-off > configuration ABI just for controlling the dentry cache.... Controlling the dirty sets (of both pages and inodes) is an important task of course, but putting the dcache management as an essential part of this is the wrong way to go methinks. > Cheers, > > Dave. -- 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
