From: Johannes Weiner <hannes@cmpxchg.org>
To: Nico Pache <npache@redhat.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, aquini@redhat.com,
shakeelb@google.com, llong@redhat.com, mhocko@suse.com,
hakavlad@inbox.lv
Subject: Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping anon memory
Date: Wed, 20 Apr 2022 14:44:32 -0400 [thread overview]
Message-ID: <YmBUkNMVDQobgK4M@cmpxchg.org> (raw)
In-Reply-To: <bc9f5209-5c59-c921-d85e-e2e54b2375db@redhat.com>
Hi Nico,
On Wed, Apr 20, 2022 at 01:34:58PM -0400, Nico Pache wrote:
> On 4/20/22 10:01, Johannes Weiner wrote:
> >> My swappiness=0 solution was a minimal approach to regaining the 'avoid swapping
> >> ANON' behavior that was previously there, but as Shakeel pointed out, there may
> >> be something larger at play.
> >
> > So with my patch and swappiness=0 you get excessive swapping on v1 but
> > not on v2? And the patch to avoid DEACTIVATE_ANON fixes it?
>
> correct, I haven't tested the DEACTIVATE_ANON patch since last time I was
> working on this, but it did cure it. I can build a new kernel with it and verify
> again.
>
> The larger issue is that our workload has regressed in performance.
>
> With V2 and swappiness=10 we are still seeing some swap, but very little tearing
> down of THPs over time. With swappiness=0 it did some when swap but we are not
> losings GBs of THPS (with your patch swappiness=0 has swap or THP issues on V2).
>
> With V1 and swappiness=(0|10)(with and without your patch), it swaps a ton and
> ultimately leads to a significant amount of THP splitting. So the longer the
> system/workload runs, the less likely we are to get THPs backing the guest and
> the performance gain from THPs is lost.
I hate to ask, but is it possible this is a configuration issue?
One significant difference between V1 and V2 is that V1 has per-cgroup
swappiness, which is inherited when the cgroup is created. So if you
set sysctl vm.swappiness=0 after cgroups have been created, it will
not update them. V2 cgroups do use vm.swappiness:
static inline int mem_cgroup_swappiness(struct mem_cgroup *memcg)
{
/* Cgroup2 doesn't have per-cgroup swappiness */
if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
return vm_swappiness;
/* root ? */
if (mem_cgroup_disabled() || mem_cgroup_is_root(memcg))
return vm_swappiness;
return memcg->swappiness;
}
Is it possible the job cgroups on V1 have swappiness=60?
> So your patch does help return the old swappiness=0 behavior, but only for V2.
Thanks for verifying. I'll prepare a proper patch.
next prev parent reply other threads:[~2022-04-20 18:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-09 22:37 [PATCH v3] vm_swappiness=0 should still try to avoid swapping anon memory Nico Pache
2021-08-10 15:27 ` Johannes Weiner
2021-08-10 19:24 ` Nico Pache
2021-08-10 21:17 ` Shakeel Butt
2021-08-10 22:16 ` Nico Pache
2021-08-10 22:29 ` Shakeel Butt
2021-08-10 21:16 ` Shakeel Butt
2021-08-10 15:37 ` Waiman Long
2022-04-19 18:11 ` Nico Pache
2022-04-19 18:46 ` Johannes Weiner
2022-04-19 19:37 ` Nico Pache
2022-04-19 23:54 ` Nico Pache
2022-04-20 14:01 ` Johannes Weiner
2022-04-20 17:34 ` Nico Pache
2022-04-20 18:44 ` Johannes Weiner [this message]
2022-04-21 16:21 ` Nico Pache
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=YmBUkNMVDQobgK4M@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=hakavlad@inbox.lv \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llong@redhat.com \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=shakeelb@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.