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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE497C433EF for ; Wed, 11 May 2022 07:23:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B29F6B0075; Wed, 11 May 2022 03:23:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 562E26B0078; Wed, 11 May 2022 03:23:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DCD88D0001; Wed, 11 May 2022 03:23:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2F7C96B0075 for ; Wed, 11 May 2022 03:23:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0E994324F1 for ; Wed, 11 May 2022 07:23:36 +0000 (UTC) X-FDA: 79452622032.28.ED3956A Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by imf14.hostedemail.com (Postfix) with ESMTP id 62DD31000A0 for ; Wed, 11 May 2022 07:23:33 +0000 (UTC) Received: by mail-io1-f52.google.com with SMTP id s23so1159445iog.13 for ; Wed, 11 May 2022 00:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aJSkUgLXvualcu4yScFNgMcnLoh/M7+w0nEwWnW4pbs=; b=cj77kxh/M2LDVTpVxQojt06kHiCwZik0yMWg84kwgaBpWv0OvH+OF0I9uUiCDdo27i a0mqHBBFXFURc6yyAA2l8Iy0PFNTeDPlmCCWoKnSlF5Sikk/UTxshwtA8zRW756wXuiY yf8CEbmTrAngMsngIGr0TpwT92kzwZ7owMaguKQNb0NVOfxBNlo11U+fEwtsIKO1y4Oe n2OLd88b4zcAPMTifMTnT/TojDZOgfBIWU/iW1Zsn498Chc9+Z6A5CbN9TYnExji7Vzn FxarmoF0Iz2pcul4TVFxp6otlhQqS5o9LAaaItAgPOYMr2pHKwUc3VKqppdrFLpku7x3 hiow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aJSkUgLXvualcu4yScFNgMcnLoh/M7+w0nEwWnW4pbs=; b=dBpw9bui7ls7IEbQPMWnwadti5kZcWPEwMguAYr2sQ/3ftdrQxruP7gLdB6RV+cXJV /aCKdtelKj+rFOeOj0m0HuY4V6oPhnXO0E0p8FFGJF3p21dQ8yXetPZK9xlAmocxLVLC 73+m3ViTZC6cLIOOB3UzuzM5fwEIEX6J5CGbxH54otgzIr6T1z8gXvFijIswmkIBbPX4 L7zvevb38zJdtihGVbZlieFKtH2UviZy6ApKcsSoW5R/9wXXO/i/AdI1X0wEyCbaA0R3 0I4TryE3FM1V7RdvnbUKTrPWbBs7jP8b8dOu/hIkb2LAa3sDhpExwFbEGiWSKO56nILI CMcQ== X-Gm-Message-State: AOAM530k3LMIm5oQIY1jixlhMxlsdiAcxCBo2o6OQ2bitlbmt8Ne2MzG SokNwxsyZkfTy2l0EqpaFXPLgu51ggBnnaIXmfAadg== X-Google-Smtp-Source: ABdhPJw2WmHk1nrcKec1xt11oLF+VeS1JW2lmCKlopF2TR+OwhXGa1zfRYeYHD+OmiUtZBUu/q/4j52wRpaAXFy2yLA= X-Received: by 2002:a05:6638:140d:b0:32b:c643:e334 with SMTP id k13-20020a056638140d00b0032bc643e334mr11756608jad.125.1652253814626; Wed, 11 May 2022 00:23:34 -0700 (PDT) MIME-Version: 1.0 References: <20220507050916.GA13577@us192.sjc.aristanetworks.com> In-Reply-To: From: Ganesan Rajagopal Date: Wed, 11 May 2022 12:52:57 +0530 Message-ID: Subject: Re: [PATCH v2] mm/memcontrol: Export memcg->watermark via sysfs for v2 memcg To: Michal Hocko Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeelb@google.com, cgroups@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 8ro6f38m3cudhimuxxdfdfc7tgx1pk3u X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 62DD31000A0 X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=arista.com header.s=google header.b="cj77kxh/"; dmarc=pass (policy=reject) header.from=arista.com; spf=none (imf14.hostedemail.com: domain of rganesan@arista.com has no SPF policy when checking 209.85.166.52) smtp.mailfrom=rganesan@arista.com X-HE-Tag: 1652253813-211410 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 Wed, May 11, 2022 at 12:43 PM Michal Hocko wrote: > > On Fri 06-05-22 22:09:16, Ganesan Rajagopal wrote: > > We run a lot of automated tests when building our software and run into > > OOM scenarios when the tests run unbounded. v1 memcg exports > > memcg->watermark as "memory.max_usage_in_bytes" in sysfs. We use this > > metric to heuristically limit the number of tests that can run in > > parallel based on per test historical data. > > > > This metric is currently not exported for v2 memcg and there is no > > other easy way of getting this information. getrusage() syscall returns > > "ru_maxrss" which can be used as an approximation but that's the max > > RSS of a single child process across all children instead of the > > aggregated max for all child processes. The only work around is to > > periodically poll "memory.current" but that's not practical for > > short-lived one-off cgroups. > > > > Hence, expose memcg->watermark as "memory.peak" for v2 memcg. > > Yes, I can imagine that a very short lived process can easily escape > from the monitoring. The memory consumption can be still significant > though. > > The v1 interface allows to reset the value by writing to the file. Have > you considered that as well? I hadn't originally but this was discussed and dropped when I posted the first version of this patch. See https://www.spinics.net/lists/cgroups/msg32476.html Ganesan > > > Signed-off-by: Ganesan Rajagopal > > Acked-by: Michal Hocko > > > --- > > Documentation/admin-guide/cgroup-v2.rst | 7 +++++++ > > mm/memcontrol.c | 13 +++++++++++++ > > 2 files changed, 20 insertions(+) > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > index 69d7a6983f78..828ce037fb2a 100644 > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -1208,6 +1208,13 @@ PAGE_SIZE multiple when read back. > > high limit is used and monitored properly, this limit's > > utility is limited to providing the final safety net. > > > > + memory.peak > > + A read-only single value file which exists on non-root > > + cgroups. > > + > > + The max memory usage recorded for the cgroup and its > > + descendants since the creation of the cgroup. > > + > > memory.oom.group > > A read-write single value file which exists on non-root > > cgroups. The default value is "0". > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 725f76723220..88fa70b5d8af 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -6098,6 +6098,14 @@ static u64 memory_current_read(struct cgroup_subsys_state *css, > > return (u64)page_counter_read(&memcg->memory) * PAGE_SIZE; > > } > > > > +static u64 memory_peak_read(struct cgroup_subsys_state *css, > > + struct cftype *cft) > > +{ > > + struct mem_cgroup *memcg = mem_cgroup_from_css(css); > > + > > + return (u64)memcg->memory.watermark * PAGE_SIZE; > > +} > > + > > static int memory_min_show(struct seq_file *m, void *v) > > { > > return seq_puts_memcg_tunable(m, > > @@ -6361,6 +6369,11 @@ static struct cftype memory_files[] = { > > .flags = CFTYPE_NOT_ON_ROOT, > > .read_u64 = memory_current_read, > > }, > > + { > > + .name = "peak", > > + .flags = CFTYPE_NOT_ON_ROOT, > > + .read_u64 = memory_peak_read, > > + }, > > { > > .name = "min", > > .flags = CFTYPE_NOT_ON_ROOT, > > -- > > 2.28.0 > > -- > Michal Hocko > SUSE Labs