From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE950C072A4 for ; Wed, 22 May 2019 05:30:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 77D3220862 for ; Wed, 22 May 2019 05:30:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZZ7LukV0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77D3220862 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CFAF26B0003; Wed, 22 May 2019 01:30:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CAAA06B0006; Wed, 22 May 2019 01:30:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B72406B0007; Wed, 22 May 2019 01:30:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by kanga.kvack.org (Postfix) with ESMTP id 687CB6B0003 for ; Wed, 22 May 2019 01:30:32 -0400 (EDT) Received: by mail-wr1-f70.google.com with SMTP id r7so603033wrn.8 for ; Tue, 21 May 2019 22:30:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:mime-version:references :in-reply-to:from:date:message-id:subject:to:cc; bh=khAfVgyvdFpD+3BrbDMKT8RJLVGP4g3H+a67pFViOXc=; b=NPw65c8apYhVH6ifTitY9rKs9nAbf7k0naYl4DytA6o4SwadaTGpTfzwwzTjQz0JHe dydwZdfsalz3o7Hvvye+DNF+GFAnguKPpmyfM+KEOWSKGPbYnaQsA9XL7medz5nEFGHK 4h4o8oVhFvrb7g63YHkzAnjI7yCSebQDwnxLsVa+NykGAVcsEhswCJFx8H50/xa47y5e O8uEkIWhvWlrsZjPsrNSBxNiKuMufbTPIaZPeYBnpQfZ3u0LEqwM3MhCuHGpztDMMBTz Zm4AGVa21L+Xp2wjaTLZv+sHkqpeY39o6+m2eLjGhv1qVdFFIJCHe2ki1OS+n7h3GIiJ R/vw== X-Gm-Message-State: APjAAAWpNmWbvTJkVjapUpi/RKvH6jbdnbCKkIjJibOXnV59O8tOac1f Aqx3+gYp2FrLxXUtxP0NrlFrzdayGxL8BM7uUK4GbF8RZGLVdbJU9davVfmR+WmiM/+djoe7pDf pw1doQFTCk1qYLsZImFB6iysaq20XpPe+kxi0NIA/V4U/gTI6Ghdbc5lNrVeGjMjfBQ== X-Received: by 2002:adf:e9ca:: with SMTP id l10mr5762575wrn.47.1558503031798; Tue, 21 May 2019 22:30:31 -0700 (PDT) X-Received: by 2002:adf:e9ca:: with SMTP id l10mr5762516wrn.47.1558503030876; Tue, 21 May 2019 22:30:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558503030; cv=none; d=google.com; s=arc-20160816; b=UapoiEYfLQZBWU+oocOu396awyosoEVfI2k78uvf2OsFz4J3u8BBPMsgMX6P4S0Fj9 yJlSa8KVedBl8ncZhX1ZC8e2heiR1kIJqCWbBvgePOjJqJxmUCje8IUW//yz/h5f5HC0 F/FRZjKn0ZsFMGm5GzbJ4YgEufKQaC8PiAoA3zYE+vrdxkzJTXodfQwCz6JUdCGnm/id e2rcSKKpn6uiXbuIzyM/11SzW8tG1WgEOzbwbXIFUh5sOtIhx7HcKKpzIQd797AQgn6x K2JKeqfAjRWtiPMWJNdj0XmSWhQBgd3vc4hBNagBwnk2rKZXUgpvwXsghFiq2Jp3262x REAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=khAfVgyvdFpD+3BrbDMKT8RJLVGP4g3H+a67pFViOXc=; b=0EjBfuc7xLy+qy/pD7VRuESo7kMkY96iCMn5dQ12NyxsNdAzc1soD7rHy9ZM1euuJT Bu8JfTzu32S1SN2xZV5SU5/JdrvxBHWZ4PZWIOR1TxYL6/aJXuHvATAY9EX6R6z5jw0d GcXn3V6Lr8JzJge1lU93bmDi8gfh3GtGr4XIbsMoHv8I2uMelQ6TnUiIqboa/ukhtGzs hTBNhuHbV4y4N1GZGM1PpxT7mo1+ZxN2K9LUjuD/jPpJqccHxNGDhVD8czfTcYePO0qa GqOYzGpPQ3zzNDfhOp5SUz0N8YQctC44A3eaTaC4cFXSieRpetpusjnoxtnyRLRpQCIw VPpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZZ7LukV0; spf=pass (google.com: domain of surenb@google.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id q18sor7873577wre.28.2019.05.21.22.30.30 for (Google Transport Security); Tue, 21 May 2019 22:30:30 -0700 (PDT) Received-SPF: pass (google.com: domain of surenb@google.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZZ7LukV0; spf=pass (google.com: domain of surenb@google.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=khAfVgyvdFpD+3BrbDMKT8RJLVGP4g3H+a67pFViOXc=; b=ZZ7LukV0216gLYaha22MBJ0hKw12PTjtcsOtESvqoFx2r8YXGyqNWCUCL45b1wedZD ZFNWVfSTZF3ZUou6Ksk4uYSJh+d2PC9HQrQiSG61+UoTKm1c9yaPNHD4fJTQWFZMRDO1 pr1LvFbHpOEBHuWFtKevEqMDfMCiVnTOiK32GFFeU4bRc0EOQ9F0EUlN+nXzNlwHA2xB hQ+rsJCfg5ODxzSI7HUVjPStRo09JWJ9UWqRkFyoIqvsnPMHk9INdC3ytAPm5PWhOsph E3085FTjpiN+d9BzuykZ7awBQxQAum0qGAUnNW0nyIyMIH8p6w0wV2frQdhQNhhaStrI q/LQ== X-Google-Smtp-Source: APXvYqyHeIQKj0Z4wRld3Nv42dTU/iH3BbSC9pIZ0KcQpdW6gcf7eqXRf/Bm3IQyDDtmyAz5PGReJvK72TbhosnXntk= X-Received: by 2002:adf:ab45:: with SMTP id r5mr26865834wrc.100.1558503029912; Tue, 21 May 2019 22:30:29 -0700 (PDT) MIME-Version: 1.0 References: <20190212224542.ZW63a%akpm@linux-foundation.org> <20190213124729.GI4525@dhcp22.suse.cz> <20190516175655.GA25818@cmpxchg.org> <20190516180932.GA13208@dhcp22.suse.cz> <20190516193943.GA26439@cmpxchg.org> <20190517123310.GI6836@dhcp22.suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 21 May 2019 22:30:18 -0700 Message-ID: Subject: Re: + mm-consider-subtrees-in-memoryevents.patch added to -mm tree To: Shakeel Butt Cc: Michal Hocko , Johannes Weiner , Andrew Morton , mm-commits@vger.kernel.org, Tejun Heo , Roman Gushchin , Dennis Zhou , Chris Down , cgroups mailinglist , Linux MM Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 17, 2019 at 6:00 AM Shakeel Butt wrote: > > On Fri, May 17, 2019 at 5:33 AM Michal Hocko 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@dhcp22.suse.cz > > > > > > > > > > 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 >