From: Michal Hocko <mhocko@suse.com>
To: Wei Xu <weixugc@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Yosry Ahmed <yosryahmed@google.com>,
Shakeel Butt <shakeelb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Cgroups <cgroups@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
Linux-MM <linux-mm@kvack.org>, Yu Zhao <yuzhao@google.com>,
Greg Thelen <gthelen@google.com>,
Chen Wandun <chenwandun@huawei.com>
Subject: Re: [RFC] Add swappiness argument to memory.reclaim
Date: Thu, 19 May 2022 10:51:53 +0200 [thread overview]
Message-ID: <YoYFKdqayKRw2npp@dhcp22.suse.cz> (raw)
In-Reply-To: <CAAPL-u8pZ_p+SQZnr=8UV37yiQpWRZny7g9p6YES0wa+g_kMJw@mail.gmail.com>
On Wed 18-05-22 22:44:13, Wei Xu wrote:
> On Tue, May 17, 2022 at 1:06 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
[...]
> > But I don't think an anon/file bias will capture this coefficient?
>
> It essentially provides the userspace proactive reclaimer an ability
> to define its own reclaim policy by adding an argument to specify
> which type of pages to reclaim via memory.reclaim.
I am not sure the swappiness is really a proper interface for that.
Historically this tunable has changed behavior several times and the
reclaim algorithm is free to ignore it completely in many cases. If you
want to build a userspace reclaim policy, then it really has to have a
predictable and stable behavior. That would mean that the semantic would
have to be much stronger than the global vm_swappiness.
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>
To: Wei Xu <weixugc-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Yosry Ahmed <yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Roman Gushchin
<roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Linux-MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
Yu Zhao <yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Chen Wandun <chenwandun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Subject: Re: [RFC] Add swappiness argument to memory.reclaim
Date: Thu, 19 May 2022 10:51:53 +0200 [thread overview]
Message-ID: <YoYFKdqayKRw2npp@dhcp22.suse.cz> (raw)
In-Reply-To: <CAAPL-u8pZ_p+SQZnr=8UV37yiQpWRZny7g9p6YES0wa+g_kMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed 18-05-22 22:44:13, Wei Xu wrote:
> On Tue, May 17, 2022 at 1:06 PM Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org> wrote:
[...]
> > But I don't think an anon/file bias will capture this coefficient?
>
> It essentially provides the userspace proactive reclaimer an ability
> to define its own reclaim policy by adding an argument to specify
> which type of pages to reclaim via memory.reclaim.
I am not sure the swappiness is really a proper interface for that.
Historically this tunable has changed behavior several times and the
reclaim algorithm is free to ignore it completely in many cases. If you
want to build a userspace reclaim policy, then it really has to have a
predictable and stable behavior. That would mean that the semantic would
have to be much stronger than the global vm_swappiness.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-05-19 8:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 22:29 [RFC] Add swappiness argument to memory.reclaim Yosry Ahmed
2022-05-16 22:29 ` Yosry Ahmed
2022-05-17 6:56 ` Michal Hocko
2022-05-17 6:56 ` Michal Hocko
2022-05-17 18:06 ` Yosry Ahmed
2022-05-17 18:06 ` Yosry Ahmed
2022-05-17 20:06 ` Johannes Weiner
2022-05-17 20:06 ` Johannes Weiner
2022-05-19 5:44 ` Wei Xu
2022-05-19 5:44 ` Wei Xu
2022-05-19 8:51 ` Michal Hocko [this message]
2022-05-19 8:51 ` Michal Hocko
2022-05-19 15:29 ` Wei Xu
2022-05-19 15:29 ` Wei Xu
2022-05-19 18:24 ` Yosry Ahmed
2022-05-19 18:24 ` Yosry Ahmed
2022-05-17 16:05 ` Roman Gushchin
2022-05-17 16:05 ` Roman Gushchin
2022-05-17 18:13 ` Yosry Ahmed
2022-05-17 18:13 ` Yosry Ahmed
2022-05-17 19:49 ` Roman Gushchin
2022-05-17 19:49 ` Roman Gushchin
2022-05-17 20:11 ` Yosry Ahmed
2022-05-17 20:11 ` Yosry Ahmed
2022-05-17 20:45 ` Roman Gushchin
2022-05-17 20:45 ` Roman Gushchin
2022-05-19 5:17 ` Wei Xu
2022-05-19 5:17 ` Wei Xu
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=YoYFKdqayKRw2npp@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chenwandun@huawei.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--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: 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.