From: Michal Hocko <mhocko@suse.com> To: Yosry Ahmed <yosryahmed@google.com> Cc: "David Rientjes" <rientjes@google.com>, "Johannes Weiner" <hannes@cmpxchg.org>, "Shakeel Butt" <shakeelb@google.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Roman Gushchin" <roman.gushchin@linux.dev>, "Tejun Heo" <tj@kernel.org>, "Zefan Li" <lizefan.x@bytedance.com>, "Jonathan Corbet" <corbet@lwn.net>, "Shuah Khan" <shuah@kernel.org>, "Yu Zhao" <yuzhao@google.com>, "Dave Hansen" <dave.hansen@linux.intel.com>, "Wei Xu" <weixugc@google.com>, "Greg Thelen" <gthelen@google.com>, "Chen Wandun" <chenwandun@huawei.com>, "Vaibhav Jain" <vaibhav@linux.ibm.com>, "Michal Koutný" <mkoutny@suse.com>, "Tim Chen" <tim.c.chen@linux.intel.com>, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 1/4] memcg: introduce per-memcg reclaim interface Date: Tue, 26 Apr 2022 10:22:42 +0200 [thread overview] Message-ID: <Ymer0qeaJlRY1Ju6@dhcp22.suse.cz> (raw) In-Reply-To: <CAJD7tka_96du2UUx0xuseR62wu005-KPf7fSyDTAuXOWsgUQDg@mail.gmail.com> On Mon 25-04-22 12:31:51, Yosry Ahmed wrote: > On Mon, Apr 25, 2022 at 12:15 PM David Rientjes <rientjes@google.com> wrote: [...] > > "can over or under reclaim from the target cgroup" begs the question of > > how much more memory the kernel can decide to reclaim :) I think it's > > assumed that it's minimal and that matches the current implementation that > > rounds up to SWAP_CLUSTER_MAX, though, so looks good. > > > > Thanks Yosry! > > I think it could be more complex than this. Some functions that get > called during reclaim only use the nr_to_reclaim parameter to check if > they need one more iteration, but not to limit the actual reclaimed > pages per say. For example, nr_to_reclaim is not even passed to > shrink_slab() or mem_cgroup_soft_limit_reclaim(), so they have no way > to know that they should stop if nr_to_reclaim was already satisfied. > I think the general assumption is that each of these calls normally > does not reclaim a huge number of pages, so like you said, the kernel > should not over-reclaim too much. However, I don't think there are > guarantees about this. There are no guarantees indeed and it si definitely good to be explicit about that so that userspace tools expect that and consider that in the imeplementation. Sure we do not want to go overboard and huge excess should be considered a bug. I am not sure we do agree on the notion of "huge" so let's see. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> To: Yosry Ahmed <yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: "David Rientjes" <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Johannes Weiner" <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, "Shakeel Butt" <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Andrew Morton" <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, "Roman Gushchin" <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>, "Tejun Heo" <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "Zefan Li" <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>, "Jonathan Corbet" <corbet-T1hC0tSOHrs@public.gmane.org>, "Shuah Khan" <shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "Yu Zhao" <yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Dave Hansen" <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, "Wei Xu" <weixugc-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Greg Thelen" <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, "Chen Wandun" <chenwandun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>, "Vaibhav Jain" <vaibhav-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>, "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>, "Tim Chen" <tim.c.chen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Linux Kernel Mailing List" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linux-MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org> Subject: Re: [PATCH v5 1/4] memcg: introduce per-memcg reclaim interface Date: Tue, 26 Apr 2022 10:22:42 +0200 [thread overview] Message-ID: <Ymer0qeaJlRY1Ju6@dhcp22.suse.cz> (raw) In-Reply-To: <CAJD7tka_96du2UUx0xuseR62wu005-KPf7fSyDTAuXOWsgUQDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon 25-04-22 12:31:51, Yosry Ahmed wrote: > On Mon, Apr 25, 2022 at 12:15 PM David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: [...] > > "can over or under reclaim from the target cgroup" begs the question of > > how much more memory the kernel can decide to reclaim :) I think it's > > assumed that it's minimal and that matches the current implementation that > > rounds up to SWAP_CLUSTER_MAX, though, so looks good. > > > > Thanks Yosry! > > I think it could be more complex than this. Some functions that get > called during reclaim only use the nr_to_reclaim parameter to check if > they need one more iteration, but not to limit the actual reclaimed > pages per say. For example, nr_to_reclaim is not even passed to > shrink_slab() or mem_cgroup_soft_limit_reclaim(), so they have no way > to know that they should stop if nr_to_reclaim was already satisfied. > I think the general assumption is that each of these calls normally > does not reclaim a huge number of pages, so like you said, the kernel > should not over-reclaim too much. However, I don't think there are > guarantees about this. There are no guarantees indeed and it si definitely good to be explicit about that so that userspace tools expect that and consider that in the imeplementation. Sure we do not want to go overboard and huge excess should be considered a bug. I am not sure we do agree on the notion of "huge" so let's see. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2022-04-26 8:23 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-25 19:00 [PATCH v5 0/4] memcg: introduce per-memcg proactive reclaim Yosry Ahmed 2022-04-25 19:00 ` Yosry Ahmed 2022-04-25 19:00 ` [PATCH v5 1/4] memcg: introduce per-memcg reclaim interface Yosry Ahmed 2022-04-25 19:00 ` Yosry Ahmed 2022-04-25 19:15 ` David Rientjes 2022-04-25 19:15 ` David Rientjes 2022-04-25 19:31 ` Yosry Ahmed 2022-04-25 19:31 ` Yosry Ahmed 2022-04-26 8:22 ` Michal Hocko [this message] 2022-04-26 8:22 ` Michal Hocko 2022-05-04 0:13 ` Davidlohr Bueso 2022-05-04 0:13 ` Davidlohr Bueso 2022-04-25 19:00 ` [PATCH v5 2/4] selftests: cgroup: return -errno from cg_read()/cg_write() on failure Yosry Ahmed 2022-04-25 19:17 ` David Rientjes 2022-04-25 19:17 ` David Rientjes 2022-04-26 1:53 ` Roman Gushchin 2022-04-26 1:53 ` Roman Gushchin 2022-04-25 19:00 ` [PATCH v5 3/4] selftests: cgroup: fix alloc_anon_noexit() instantly freeing memory Yosry Ahmed 2022-04-25 19:18 ` David Rientjes 2022-04-25 19:00 ` [PATCH v5 4/4] selftests: cgroup: add a selftest for memory.reclaim Yosry Ahmed 2022-04-25 19:00 ` Yosry Ahmed 2022-04-25 19:21 ` David Rientjes
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Ymer0qeaJlRY1Ju6@dhcp22.suse.cz \ --to=mhocko@suse.com \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=chenwandun@huawei.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@linux.intel.com \ --cc=gthelen@google.com \ --cc=hannes@cmpxchg.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lizefan.x@bytedance.com \ --cc=mkoutny@suse.com \ --cc=rientjes@google.com \ --cc=roman.gushchin@linux.dev \ --cc=shakeelb@google.com \ --cc=shuah@kernel.org \ --cc=tim.c.chen@linux.intel.com \ --cc=tj@kernel.org \ --cc=vaibhav@linux.ibm.com \ --cc=weixugc@google.com \ --cc=yosryahmed@google.com \ --cc=yuzhao@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.