On Fri, May 17, 2019 at 6:00 AM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > On Fri, May 17, 2019 at 5:33 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > On Thu 16-05-19 15:39:43, Johannes Weiner wrote: > > > On Thu, May 16, 2019 at 08:10:42PM +0200, Michal Hocko wrote: > > > > On Thu 16-05-19 13:56:55, Johannes Weiner wrote: > > > > > On Wed, Feb 13, 2019 at 01:47:29PM +0100, Michal Hocko wrote: > > [...] > > > > > > FTR: As I've already said here [1] I can live with this change as long > > > > > > as there is a larger consensus among cgroup v2 users. So let's give this > > > > > > some more time before merging to see whether there is such a consensus. > > > > > > > > > > > > [1] http://lkml.kernel.org/r/20190201102515.GK11599@xxxxxxxxxxxxxx > > > > > > > > > > It's been three months without any objections. > > > > > > > > It's been three months without any _feedback_ from anybody. It might > > > > very well be true that people just do not read these emails or do not > > > > care one way or another. > > > > > > This is exactly the type of stuff that Mel was talking about at LSFMM > > > not even two weeks ago. How one objection, however absurd, can cause > > > "controversy" and block an effort to address a mistake we have made in > > > the past that is now actively causing problems for real users. > > > > > > And now after stalling this fix for three months to wait for unlikely > > > objections, you're moving the goal post. This is frustrating. > > > > I see your frustration but I find the above wording really unfair. Let me > > remind you that this is a considerable user visible change in the > > semantic and that always has to be evaluated carefuly. A change that would > > clearly regress anybody who rely on the current semantic. This is not an > > internal implementation detail kinda thing. > > > > I have suggested an option for the new behavior to be opt-in which > > would be a regression safe option. You keep insisting that we absolutely > > have to have hierarchical reporting by default for consistency reasons. > > I do understand that argument but when I weigh consistency vs. potential > > regression risk I rather go a conservative way. This is a traditional > > way how we deal with semantic changes like this. There are always > > exceptions possible and that is why I wanted to hear from other users of > > cgroup v2, even from those who are not directly affected now. > > > > If you feel so stronly about this topic and the suggested opt-in is an > > absolute no-go then you are free to override my opinion here. I haven't > > Nacked this patch. > > > > > Nobody else is speaking up because the current user base is very small > > > and because the idea that anybody has developed against and is relying > > > on the current problematic behavior is completely contrived. In > > > reality, the behavior surprises people and causes production issues. > > > > I strongly suspect users usually do not follow discussions on our > > mailing lists. They only come up later when something breaks and that > > is too late. I do realize that this makes the above call for a wider > > consensus harder but a lack of upstream bug reports also suggests that > > people do not care or simply haven't noticed any issues due to way how > > they use the said interface (maybe deeper hierarchies are not that > > common). > > > > I suspect that FB is the only one using cgroup v2 in production and > others (data center) users are still evaluating/exploring. Also IMHO > the cgroup v2 users are on the bleeding edge. As new cgroup v2 > features and controllers are added, the users either switch to latest > kernel or backport. That might be the reason no one objected. Also > none of the distribution has defaulted to v2 yet, so, not many > transparent v2 users yet. In Android we are not using cgroups v2 yet (and that's why I was refraining from commenting earlier), however when I was evaluating them for future use I was disappointed that events do not propagate up the hierarchy. One usecase that I was considering is to get a notification when OOM kill happens. With cgroups v2 we would be forced to use per-app hierarchy to avoid process migrations between memcgs when an app changes its state (background/foreground). With such a setup we would end up with many leaf cgroups. Polling each individual leaf cgroup's memory.events file to detect OOM occurrence would require lots of extra FDs registered with an epoll(). Having an ability to poll a common parent cgroup to detect that one of the leafs generated an OOM event would be way more frugal. I realize this does not constitute a real-life usecase but hopefully possible usecases can provide some value too. Thanks, Suren. > Shakeel >
