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 A32A4C433F5 for ; Fri, 1 Apr 2022 09:16:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 185AD8D0002; Fri, 1 Apr 2022 05:16:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 10F658D0001; Fri, 1 Apr 2022 05:16:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F18458D0002; Fri, 1 Apr 2022 05:16:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id DF4E78D0001 for ; Fri, 1 Apr 2022 05:16:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AA018218D for ; Fri, 1 Apr 2022 09:16:19 +0000 (UTC) X-FDA: 79307754078.15.7BD57F0 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf09.hostedemail.com (Postfix) with ESMTP id E88E2140016 for ; Fri, 1 Apr 2022 09:16:18 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id x31so2076526pfh.9 for ; Fri, 01 Apr 2022 02:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mVtM4JSAbem5vI9+iuqfBK73jb3O87WJ5L8y1a9lG0k=; b=qBhXowGyC8QPVrqYIiBrDRqGidNxRPybkTr1qpdVQuxv2f1BsLDxISO4qXFuFcNK7k CjkH1IIsBGXG5QGrrQilYhMyUyVQ6Ffguxz8o4aPErdkR+RyesWbakUcwsTVHuRnggU5 41PA8xIK8/aT4fT3MRjvLBsVrYLlprc8AQiOzUWqTvvbWJjGQ6I/nhZQoH/ahBpr5noN O2+Eq72KeLQLXtISp5EFkDKwDOvhw5J4Wx3vr2sHnwgWl4dGDROEQ3tfLw7yGl0x5C+q XLbIfJS6nMf3DsP5oxD6k4cHALXNs2ggeBrQWfkIHsrAf++kuBxMf6i5Pqxf1SogT8Mo nUVg== 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=mVtM4JSAbem5vI9+iuqfBK73jb3O87WJ5L8y1a9lG0k=; b=qm/C6lzMBHVKvd3Lvwv633ggjgKjHVXiDNZjmhULed/LLTNHFjVrmTOikmn9HJBazI eK1R1BKM58DBscoZxQMD1jqhCmnMudO/ETkNatpyOhpGy09TYyxCYiRo59EH0GY/lPeX x9max6oRSizWdMMkzpfvYRU4wb17KwNU9wSetwIuf0cDkDZ/4+kXGzL2odYvG++VSdYD y0NozlDQRxKrHwvX9hewFNw7a6DCZ2KoWRDBxnN44ayaoHkk+Xh4JdLZ0WelfyV0qAna 6yHpXooMwGBGYeKn1jwNDdVM11O8V3p48WzFGp4P8kEG4HcLUjNSrBajz1lv4/96w4RG mZrw== X-Gm-Message-State: AOAM533FswNZirndMs3TJKwFx+rzoi03jKqpDgE57K+2NlOXCiUtlolV RWZtmt0Q1TBSHMXY3uPrxDS+SfHiKSXhJPPoPkOfSg== X-Google-Smtp-Source: ABdhPJxVpSge4lhANEie6/fjIW+bzMrkYinehipLbgvk+7CkO338yLhmViJP9F1aNuuv60tpEIk5t5ZrXK2q7845Y2c= X-Received: by 2002:a63:ff63:0:b0:386:327:5353 with SMTP id s35-20020a63ff63000000b0038603275353mr14022888pgk.401.1648804577681; Fri, 01 Apr 2022 02:16:17 -0700 (PDT) MIME-Version: 1.0 References: <20220331084151.2600229-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 1 Apr 2022 02:15:41 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Linux-MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Wei Xu , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: qufr7hmgxomq658p4tfr1xxy1nhzjxnx Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qBhXowGy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspamd-Queue-Id: E88E2140016 X-HE-Tag: 1648804578-623515 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 Thu, Mar 31, 2022 at 10:25 AM Roman Gushchin wrote: > > On Thu, Mar 31, 2022 at 08:41:51AM +0000, Yosry Ahmed wrote: > > From: Shakeel Butt > > > > Introduce an memcg interface to trigger memory reclaim on a memory cgroup. > > > > Use case: Proactive Reclaim > > --------------------------- > > > > A userspace proactive reclaimer can continuously probe the memcg to > > reclaim a small amount of memory. This gives more accurate and > > up-to-date workingset estimation as the LRUs are continuously > > sorted and can potentially provide more deterministic memory > > overcommit behavior. The memory overcommit controller can provide > > more proactive response to the changing behavior of the running > > applications instead of being reactive. > > > > A userspace reclaimer's purpose in this case is not a complete replacement > > for kswapd or direct reclaim, it is to proactively identify memory savings > > opportunities and reclaim some amount of cold pages set by the policy > > to free up the memory for more demanding jobs or scheduling new jobs. > > > > A user space proactive reclaimer is used in Google data centers. > > Additionally, Meta's TMO paper recently referenced a very similar > > interface used for user space proactive reclaim: > > https://dl.acm.org/doi/pdf/10.1145/3503222.3507731 > > > > Benefits of a user space reclaimer: > > ----------------------------------- > > > > 1) More flexible on who should be charged for the cpu of the memory > > reclaim. For proactive reclaim, it makes more sense to be centralized. > > > > 2) More flexible on dedicating the resources (like cpu). The memory > > overcommit controller can balance the cost between the cpu usage and > > the memory reclaimed. > > > > 3) Provides a way to the applications to keep their LRUs sorted, so, > > under memory pressure better reclaim candidates are selected. This also > > gives more accurate and uptodate notion of working set for an > > application. > > > > Why memory.high is not enough? > > ------------------------------ > > > > - memory.high can be used to trigger reclaim in a memcg and can > > potentially be used for proactive reclaim. > > However there is a big downside in using memory.high. It can potentially > > introduce high reclaim stalls in the target application as the > > allocations from the processes or the threads of the application can hit > > the temporary memory.high limit. > > > > - Userspace proactive reclaimers usually use feedback loops to decide > > how much memory to proactively reclaim from a workload. The metrics > > used for this are usually either refaults or PSI, and these metrics > > will become messy if the application gets throttled by hitting the > > high limit. > > > > - memory.high is a stateful interface, if the userspace proactive > > reclaimer crashes for any reason while triggering reclaim it can leave > > the application in a bad state. > > > > - If a workload is rapidly expanding, setting memory.high to proactively > > reclaim memory can result in actually reclaiming more memory than > > intended. > > > > The benefits of such interface and shortcomings of existing interface > > were further discussed in this RFC thread: > > https://lore.kernel.org/linux-mm/5df21376-7dd1-bf81-8414-32a73cea45dd@google.com/ > > Hello! > > I'm totally up for the proposed feature! It makes total sense and is proved > to be useful, let's add it. > > > > > Interface: > > ---------- > > > > Introducing a very simple memcg interface 'echo 10M > memory.reclaim' to > > trigger reclaim in the target memory cgroup. > > > > > > Possible Extensions: > > -------------------- > > > > - This interface can be extended with an additional parameter or flags > > to allow specifying one or more types of memory to reclaim from (e.g. > > file, anon, ..). > > > > - The interface can also be extended with a node mask to reclaim from > > specific nodes. This has use cases for reclaim-based demotion in memory > > tiering systens. > > > > - A similar per-node interface can also be added to support proactive > > reclaim and reclaim-based demotion in systems without memcg. > > Maybe an option to specify a timeout? That might simplify the userspace part. > Also, please please add a test to selftests/cgroup/memcg tests. > It will also provide an example on how the userspace can use the feature. > > > > > For now, let's keep things simple by adding the basic functionality. > > What I'm worried about is how we gonna extend it? How do you see the interface > with 2-3 extensions from the list above? All these extensions look very > reasonable to me, so we'll likely have to implement them soon. So let's think > about the extensibility now. > > I wonder if it makes more sense to introduce a sys_reclaim() syscall instead? > In the end, such a feature might make sense on the system level too. > Yes, there is the drop_caches sysctl, but it's too radical for many cases. > > > > > [yosryahmed@google.com: refreshed to current master, updated commit > > message based on recent discussions and use cases] > > Signed-off-by: Shakeel Butt > > Signed-off-by: Yosry Ahmed > > --- > > Documentation/admin-guide/cgroup-v2.rst | 9 ++++++ > > mm/memcontrol.c | 37 +++++++++++++++++++++++++ > > 2 files changed, 46 insertions(+) > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > index 69d7a6983f78..925aaabb2247 100644 > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -1208,6 +1208,15 @@ 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.reclaim > > + A write-only file which exists on non-root cgroups. > > + > > + This is a simple interface to trigger memory reclaim in the > > + target cgroup. Write the number of bytes to reclaim to this > > + file and the kernel will try to reclaim that much memory. > > + Please note that the kernel can over or under reclaim from > > + the target 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..994849fab7df 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -6355,6 +6355,38 @@ static ssize_t memory_oom_group_write(struct kernfs_open_file *of, > > return nbytes; > > } > > > > +static ssize_t memory_reclaim(struct kernfs_open_file *of, char *buf, > > + size_t nbytes, loff_t off) > > +{ > > + struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of)); > > + unsigned int nr_retries = MAX_RECLAIM_RETRIES; > > + unsigned long nr_to_reclaim, nr_reclaimed = 0; > > + int err; > > + > > + buf = strstrip(buf); > > + err = page_counter_memparse(buf, "", &nr_to_reclaim); > > + if (err) > > + return err; > > + > > + while (nr_reclaimed < nr_to_reclaim) { > > + unsigned long reclaimed; > > + > > + if (signal_pending(current)) > > + break; > > + > > + reclaimed = try_to_free_mem_cgroup_pages(memcg, > > + nr_to_reclaim - nr_reclaimed, > > + GFP_KERNEL, true); > > + > > + if (!reclaimed && !nr_retries--) > > + break; > > + > > + nr_reclaimed += reclaimed; > > + } > > + > > + return nbytes; > > +} > > + > > static struct cftype memory_files[] = { > > { > > .name = "current", > > @@ -6413,6 +6445,11 @@ static struct cftype memory_files[] = { > > .seq_show = memory_oom_group_show, > > .write = memory_oom_group_write, > > }, > > + { > > + .name = "reclaim", > > + .flags = CFTYPE_NOT_ON_ROOT | CFTYPE_NS_DELEGATABLE, > > + .write = memory_reclaim, > > Btw, why not on root? I missed the root question in my first reply. I think this was originally modeled after the memory.high interface, but I don't know if there are other reasons. Shakeel would know better. AFAIK this should work naturally on root as well, but I think it makes more sense then to use a global interface (hopefully introduced soon)? I don't have an opinion here let me know what you prefer for v2.