Michal Hocko wrote: > Richard Davies wrote: > > Dwight Engen wrote: > > > Is there a plan to separately account/limit stack pages vs kmem in > > > general? Richard would have to verify, but I suspect kmem is not > > > currently viable as a process limiter for him because > > > icache/dcache/stack is all accounted together. > > > > Certainly I would like to be able to limit container fork-bombs without > > limiting the amount of disk IO caching for processes in those containers. > > > > In my testing with of kmem limits, I needed a limit of 256MB or lower to > > catch fork bombs early enough. I would definitely like more than 256MB of > > disk caching. > > > > So if we go the "working kmem" route, I would like to be able to specify a > > limit excluding disk cache. > > Page cache (which is what you mean by disk cache probably) is a > userspace accounted memory with the memory cgroup controller. And you > do not have to limit that one. OK, that's helpful - thanks. As an aside, with the normal (non-kmem) cgroup controller, is there a way for me to exclude page cache and only limit the equivalent of the rss line in memory.stat? e.g. say I have a 256GB physical machine, running 200 containers, each with 1GB normal-mem limit (for running software) and 256MB kmem limit (to stop fork-bombs). The physical disk IO bandwidth is a shared resource between all the containers, so ideally I would like the kernel to used the 56GB of RAM as shared page cache however it best reduces physical IOPs, rather than having a per-container limit. Thanks, Richard. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>