From: Chris Down <chris@chrisdown.name>
To: Andrea Righi <andrea.righi@canonical.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Li Zefan <lizefan@huawei.com>, Tejun Heo <tj@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Luigi Semenzato <semenzato@google.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH RFC v2] Opportunistic memory reclaim
Date: Mon, 5 Oct 2020 15:46:12 +0100 [thread overview]
Message-ID: <20201005144612.GB108347@chrisdown.name> (raw)
In-Reply-To: <20201005135130.GA850459@xps-13-7390>
Andrea Righi writes:
>senpai is focused at estimating the ideal memory requirements without
>affecting performance. And this covers the use case about reducing
>memory footprint.
>
>In my specific use-case (hibernation) I would let the system use as much
>memory as possible if it's doing any activity (reclaiming memory only
>when the kernel decides that it needs to reclaim memory) and apply a
>more aggressive memory reclaiming policy when the system is mostly idle.
From this description, I don't see any reason why it needs to be implemented in
kernel space. All of that information is available to userspace, and all of the
knobs are there.
As it is I'm afraid of the "only when the system is mostly idle" comment,
because it's usually after such periods that applications need to do large
retrievals, and now they're going to be in slowpath (eg. periodic jobs).
Such tradeoffs for a specific situation might be fine in userspace as a
distribution maintainer, but codifying them in the kernel seems premature to
me, especially for a knob which we will have to maintain forever onwards.
>I could probably implement this behavior adjusting memory.high
>dynamically, like senpai, but I'm worried about potential sudden large
>allocations that may require to respond faster at increasing
>memory.high. I think the user-space triggered memory reclaim approach is
>a safer solution from this perspective.
Have you seen Shakeel's recent "per-memcg reclaim interface" patches? I suspect
they may help you there.
next prev parent reply other threads:[~2020-10-05 14:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 8:13 [PATCH RFC v2] Opportunistic memory reclaim Andrea Righi
2020-10-05 8:13 ` [PATCH RFC v2 1/2] mm: memcontrol: make shrink_all_memory() memcg aware Andrea Righi
2020-10-05 8:13 ` [PATCH RFC v2 2/2] mm: memcontrol: introduce opportunistic memory reclaim Andrea Righi
2020-10-05 8:35 ` [PATCH RFC v2] Opportunistic " Michal Hocko
2020-10-05 8:44 ` Andrea Righi
2020-10-05 11:25 ` Chris Down
2020-10-05 13:51 ` Andrea Righi
2020-10-05 14:46 ` Chris Down [this message]
2020-10-05 15:39 ` Andrea Righi
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=20201005144612.GB108347@chrisdown.name \
--to=chris@chrisdown.name \
--cc=akpm@linux-foundation.org \
--cc=andrea.righi@canonical.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@kernel.org \
--cc=rafael@kernel.org \
--cc=semenzato@google.com \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).