All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yosry Ahmed <yosryahmed@google.com>
To: Dan Schatzberg <schatzberg.dan@gmail.com>,
	Michal Hocko <mhocko@suse.com>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
	"Shakeel Butt" <shakeelb@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"David Rientjes" <rientjes@google.com>,
	"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 v3 1/4] memcg: introduce per-memcg reclaim interface
Date: Fri, 8 Apr 2022 13:08:26 -0700	[thread overview]
Message-ID: <CAJD7tkbFjbGJ7CnNogpGq5enh_uhP8T5c0U+ku9PfwMoVLf2gg@mail.gmail.com> (raw)
In-Reply-To: <YlBM/HlPyPUZew5N@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com>

On Fri, Apr 8, 2022 at 7:55 AM Dan Schatzberg <schatzberg.dan@gmail.com> wrote:
>
> On Fri, Apr 08, 2022 at 04:11:05PM +0200, Michal Hocko wrote:
> > Regarding "max" as a possible input. I am not really sure to be honest.
> > I can imagine that it could be legit to simply reclaim all the charges
> > (e.g. before removing the memcg) which should be achieveable by
> > reclaiming the reported consumption. Or what exactly should be the
> > semantic?
>
> Yeah, it just allows you to avoid reading memory.current to just
> reclaim everything if you can specify "max" - you're still protected
> by nretries to eventually bail out. Mostly, though I just feel like
> supporting "max" makes memory.reclaim semetric with a lot of the
> cgroup memory control files which tend to support "max".

One possible approach here is to have force_empty behavior when we
write "max" to memory.reclaim. From Google's perspective we don't have
a preference, but it seems to me like logical behavior. We can do this
either by directly calling mem_cgroup_force_empty() or just draining
stock and lrus in memory_reclaim().

This actually brings up another interesting point. Do you think we
should drain lrus if try_to_free_mem_cgroup_pages() fails to reclaim
the request amount? We can do this after the first call or before the
last one. It could introduce more evictable pages for
try_to_free_mem_cgroup_pages() to free.

WARNING: multiple messages have this Message-ID (diff)
From: Yosry Ahmed <yosryahmed@google.com>
To: Dan Schatzberg <schatzberg.dan@gmail.com>,
	Michal Hocko <mhocko@suse.com>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
	"Shakeel Butt" <shakeelb@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"David Rientjes" <rientjes@google.com>,
	"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>
Subject: Re: [PATCH v3 1/4] memcg: introduce per-memcg reclaim interface
Date: Fri, 8 Apr 2022 13:08:26 -0700	[thread overview]
Message-ID: <CAJD7tkbFjbGJ7CnNogpGq5enh_uhP8T5c0U+ku9PfwMoVLf2gg@mail.gmail.com> (raw)
In-Reply-To: <YlBM/HlPyPUZew5N@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com>

On Fri, Apr 8, 2022 at 7:55 AM Dan Schatzberg <schatzberg.dan@gmail.com> wrote:
>
> On Fri, Apr 08, 2022 at 04:11:05PM +0200, Michal Hocko wrote:
> > Regarding "max" as a possible input. I am not really sure to be honest.
> > I can imagine that it could be legit to simply reclaim all the charges
> > (e.g. before removing the memcg) which should be achieveable by
> > reclaiming the reported consumption. Or what exactly should be the
> > semantic?
>
> Yeah, it just allows you to avoid reading memory.current to just
> reclaim everything if you can specify "max" - you're still protected
> by nretries to eventually bail out. Mostly, though I just feel like
> supporting "max" makes memory.reclaim semetric with a lot of the
> cgroup memory control files which tend to support "max".

One possible approach here is to have force_empty behavior when we
write "max" to memory.reclaim. From Google's perspective we don't have
a preference, but it seems to me like logical behavior. We can do this
either by directly calling mem_cgroup_force_empty() or just draining
stock and lrus in memory_reclaim().

This actually brings up another interesting point. Do you think we
should drain lrus if try_to_free_mem_cgroup_pages() fails to reclaim
the request amount? We can do this after the first call or before the
last one. It could introduce more evictable pages for
try_to_free_mem_cgroup_pages() to free.

  reply	other threads:[~2022-04-08 20:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08  4:57 [PATCH v3 0/4] memcg: introduce per-memcg proactive reclaim Yosry Ahmed
2022-04-08  4:57 ` Yosry Ahmed
2022-04-08  4:57 ` [PATCH v3 1/4] memcg: introduce per-memcg reclaim interface Yosry Ahmed
2022-04-08 13:43   ` Dan Schatzberg
2022-04-08 13:43     ` Dan Schatzberg
2022-04-08 14:11     ` Michal Hocko
2022-04-08 14:11       ` Michal Hocko
2022-04-08 14:55       ` Dan Schatzberg
2022-04-08 14:55         ` Dan Schatzberg
2022-04-08 20:08         ` Yosry Ahmed [this message]
2022-04-08 20:08           ` Yosry Ahmed
2022-04-14 17:25           ` Yosry Ahmed
2022-04-14 17:25             ` Yosry Ahmed
2022-04-20 12:47             ` Michal Hocko
2022-04-20 12:47               ` Michal Hocko
2022-04-11  7:20         ` Michal Hocko
2022-04-11  7:20           ` Michal Hocko
2022-04-08 17:21     ` Yosry Ahmed
2022-04-08 17:21       ` Yosry Ahmed
2022-04-09  1:13   ` Roman Gushchin
2022-04-09  1:13     ` Roman Gushchin
2022-04-08  4:57 ` [PATCH v3 2/4] selftests: cgroup: return the errno of write() in cg_write() on failure Yosry Ahmed
2022-04-09  1:21   ` Yosry Ahmed
2022-04-09  1:21     ` Yosry Ahmed
2022-04-09  1:44     ` Roman Gushchin
2022-04-09  1:44       ` Roman Gushchin
2022-04-09  6:43       ` Yosry Ahmed
2022-04-09  6:43         ` Yosry Ahmed
2022-04-09  1:33   ` Roman Gushchin
2022-04-08  4:57 ` [PATCH v3 3/4] selftests: cgroup: fix alloc_anon_noexit() instantly freeing memory Yosry Ahmed
2022-04-08  4:57   ` Yosry Ahmed
2022-04-09  1:31   ` Roman Gushchin
2022-04-09  1:31     ` Roman Gushchin
2022-04-08  4:57 ` [PATCH v3 4/4] selftests: cgroup: add a selftest for memory.reclaim Yosry Ahmed
2022-04-08  4:57   ` Yosry Ahmed
2022-04-09  1:31   ` Roman Gushchin
2022-04-09  1:31     ` Roman Gushchin

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=CAJD7tkbFjbGJ7CnNogpGq5enh_uhP8T5c0U+ku9PfwMoVLf2gg@mail.gmail.com \
    --to=yosryahmed@google.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=mhocko@suse.com \
    --cc=mkoutny@suse.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=schatzberg.dan@gmail.com \
    --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=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: link
Be 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.