Hello, On Mon, Aug 15, 2022 at 05:17:03PM +0800, Zhaoyang Huang wrote: > > > IMHO, I would like to say if it makes more sense as "A given cgroup > > > always encompasses all the resources consumed in its ENABLED > > > self-including subtree." Otherwise, how should I couple with the > > > scenarios I raised in the commit message which I prefer parts of the > > > subtrees compete for "memory" while others are free for it. The free > > > here is not only without "min/low/high watermarks" but also not > > > charged to their own LRU. > > I would like to state more why these make sense. Memory cgroup is a > > little bit different to other cgroups, that is, memcg will have real > > physical resources attached, say pages. From perspective of memory > > reclaiming, it is odd to find that pages under free memcgs are charged > > to separate LRUs but without any management(no watermark control) and > > perhaps affect workingset mechanism by LRU reason. Furthermore, v2 > > should grant the groups with the right to reject the subsys which > > introduced by sibling enable, which could be deemed as v2's > > inconvenient. The memcg could also apply subtree_control to enroll all > > memory back whenever it want. > As suggested by zefan, raise the practical scenario here to make more > sense. The issue is observed in android system where per-app cgroup is > demanded by freezer subsys and part of them require memory control. > Under this scenario, less efficient memory reclaim is observed when > comparing with no memory control. It is believed that multi LRU > scanning introduces some of the overhead. Furthermore, page thrashing > is also heavier than global LRU which could be the consequences of > partial failure of WORKINGSET mechanism as LRU is too short to protect > the active pages. The basic architecture isn't gonna change and there are fundamental reasons why things are the way they are. The resources, especially the main ones, are entangled with each other - e.g. memory, io and cpu are entangled with each other through reclaim. While we aren't capturing the cpu part yet but we now do a largely acceptable job of controlling memory and io together. This is reduction of flexibility compared to cgroup1 and can cause some inconvenience when transitioning from cgroup1 but the experience has been that the pros clearly outweigh the cons. Even here, none of the problems you're listing are architectural. If there are memcg behavior problems, we should fix them in memcg, not work around by twisting the basic architecture. Are the problematic memcg behaviors reproducible in upstream? If so, can you please make a detailed report on those? Thanks. -- tejun
