Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp100341rwe; Wed, 24 Aug 2022 18:04:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR4UBTpRiZcTu0Wt1cGWXTdg7QibnuJV1LxlAeYPWKF0wFbPrq5ZE3HsBlGItd3r288MRZ1T X-Received: by 2002:a17:902:aa47:b0:172:ef81:782d with SMTP id c7-20020a170902aa4700b00172ef81782dmr1530856plr.173.1661389490246; Wed, 24 Aug 2022 18:04:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661389490; cv=none; d=google.com; s=arc-20160816; b=CM2vnc+diRjxY78ouhp0VXNrwPCWQhwQz7jHZHEMG8ORDxu1UkKthQGvqSPJJah3YG CqGnO/DaXPsEDaXW48s/vbtvDkm2wYs/MPjoC0pgR5wHAbHZJDSYQTwx0tBK+DHHGW3X 8TjDXYyAIkyZVJ6kRVGq0OPWls+iGn29HBAi4H+spBpYgkZwN7tk/rBGd2qwfeHBOoXG m15SZ/wSY1dDutlbPiYCFcmENoOFy7QgzOMdn9FbbXWOPHVhJBDj1g3ZJ4jD0PoSs2eS DUxelh27fS3ge5aqXWQ0J8WLgpHV6uUz831Ib0IN9k7hCIr433APLTbgYLpRGr/Q4SuL DFCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=u5GpYKAPqiPXiVflxFFAVwYjhQ2xT4l31F3rdQnDD0o=; b=raFpDaoWuoxm2nMvsuKAtw8pPzxRXu3p+D3mP9/WLZvutgqMJR65S8+Uv0syzRMCSY P1bJ+/geLFcZbQUMz5MrkEBCRTH0y79pP1MUHiPjDV7PgFfHRpzqdyXwhNpBkdMrVflz LvkTro/1frXPUXvsZX826EYCtfX/Aw5Gs5WirpCRE1p81Ts1+I7lBt/2PM/pplf3KKq+ 4zr6DL/Up/6rbDb4rsG7FU0mbHR5zipwFWTrpYuwvEbQDQ3AY0uyQeyFuinJrvTArgyv Vx9xzdjyBLxbsZ6hKvczwisCsC+dZjq7+umL0WG+IQvAeu8X1+tX3uQwSOd0qBXHxlFa rCWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="A/Iio860"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lx2-20020a17090b4b0200b001fafe45b14dsi2758543pjb.159.2022.08.24.18.04.37; Wed, 24 Aug 2022 18:04:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="A/Iio860"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229741AbiHYAo2 (ORCPT + 99 others); Wed, 24 Aug 2022 20:44:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230004AbiHYAoX (ORCPT ); Wed, 24 Aug 2022 20:44:23 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 475738FD4E; Wed, 24 Aug 2022 17:44:22 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id s6so14958295lfo.11; Wed, 24 Aug 2022 17:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=u5GpYKAPqiPXiVflxFFAVwYjhQ2xT4l31F3rdQnDD0o=; b=A/Iio860rhP/v2AnpLJlwrYJYcXyV6DIv9JQx+170rEWmlIhMRzeZ9l+nUAUWh62JI c7+HUkhuYDhePhYz0hBnDIf0kxXPYT4M/ZBV+H/mccKyYUoThe086rHM/Idvobh7usXz aQ9wrACY0Z3JXJeCVGOVmQknpIZLf36WPkxiBD7fWy8VN+O7qbUFOBo3a44ClzdymCK8 cn9zOMWbhdyIyrwdxiUZa+HtMGxS+1GXqgQbAaeZcF6rDiKxojIsL57dVyKueIzEDW5i YgPIUJJ32Dna6ii+VrXwF0fLGL78HBDUuiwmooSSuF5KJzA6EQ+rvmtMerH7qMgXror3 KaSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=u5GpYKAPqiPXiVflxFFAVwYjhQ2xT4l31F3rdQnDD0o=; b=S0XtLs4W1HO+76qNE5dm70YENYqZiqH6JmerFzloE1d/Gpz+r9dbiQXZGywMpe9w/n inbMqB2XCbB9tg7kSWznnCam1hEQFzORBOzECoE2UXsMc67W+BuU9TdgpTUVmTGwcj0F irqtmBKiS+ZxeFU5ZJKxi/VJTpA/19QK2Y/nRwjJgq7lQD/gQ268mAbVCAdLQrGtRsKg We2i5us6Ko15qhHq/kCzqNi0ftO67GxK078sf2fLhwBsDKJZrij/+mBBCqcJfrvwav2t qpxg5RgJHTKbDQsb98VLSOAhGJwltHxmVrfhvx1DK4GhiD88x1cKXK/gaD3FZK9ulRfp AGrA== X-Gm-Message-State: ACgBeo3xTwrFXXvq90BpSaeiaNFSDI8C5lEuG9QSr/GZ4FmlQvBbHhPo GG5sy3ssYbmUxAo09onzuZvpw2lrIcvWJobj6KhNOgmD31+vSg== X-Received: by 2002:a05:6512:1527:b0:48b:99:f3ff with SMTP id bq39-20020a056512152700b0048b0099f3ffmr386714lfb.81.1661388260398; Wed, 24 Aug 2022 17:44:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhaoyang Huang Date: Thu, 25 Aug 2022 08:43:52 +0800 Message-ID: Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited To: Michal Hocko Cc: Suren Baghdasaryan , Tejun Heo , Shakeel Butt , "zhaoyang.huang" , Johannes Weiner , Linux MM , LKML , Cgroups , Ke Wang , Zefan Li , Roman Gushchin , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 24, 2022 at 6:27 PM Michal Hocko wrote: > > On Wed 24-08-22 17:34:42, Zhaoyang Huang wrote: > > On Wed, Aug 24, 2022 at 3:50 PM Michal Hocko wrote: > > > > > > On Wed 24-08-22 10:23:14, Zhaoyang Huang wrote: > > > > On Tue, Aug 23, 2022 at 7:51 PM Michal Hocko wrote: > > > [...] > > > > > One way to achieve that would be shaping the hierarchy the following way > > > > > root > > > > > / \ > > > > > no_memcg[1] memcg[2] > > > > > |||||||| ||||| > > > > > app_cgroups app_cgroups > > > > > > > > > > with > > > > > no_memcg.subtree_control = "" > > > > > memcg.subtree_control = memory > > > > > > > > > > no? > > > > According to my understanding, No as there will be no no_memcg. All > > > > children groups under root would have its cgroup.controllers = memory > > > > as long as root has memory enabled. > > > > > > Correct > > > > > > > Under this circumstance, all > > > > descendants group under 'no_memcg' will charge memory to its parent > > > > group. > > > > > > Correct. And why is that a problem? I thought you main concern was a per > > > application LRUs. With the above configuration all app_cgroups which do > > > not require an explicit memory control will share the same (no_memcg) > > > LRU and they will be aged together. > > I can't agree since this indicates the processes want memory free > > depending on a specific hierarchy which could have been determined by > > other subsys. > > I really fail to understand your requirements. > > > IMHO, charging the pages which out of explicitly memory > > enabled group to root could solve all of the above constraints with no > > harm. > > This would break the hierarchical property of the controller. So a > strong no no. Consider the following example > > root > | > A > controllers="memory" > memory.max = 1G > subtree_control="" > | | | > A1 A2 A3 > > althought A1,2,3 do not have their memory controller enabled explicitly > they are still constrained by the A memcg limit. If you just charge to > the root because it doesn't have memory controller enabled explicitly > then you just evade that constrain. I hope you understand why that is a > problem. IMO, A1-A3 should be explicitly enabled via echo "+memory" > A/subtree_control since memory.max has been set. How should AA3 achieve the goal of compete with AA4,A1,A2 for cpu but keep memory out of control under current policy? root | A controllers="memory,cpu" memory.max = 1G subtree_control="memory,cpu" | | | A1 A2 A3 subtree_control="cpu" | | AA3 AA4 controllers="cpu" > -- > Michal Hocko > SUSE Labs