From: Nico Pache <npache@redhat.com>
To: Alexey Avramov <hakavlad@inbox.lv>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, hannes@cmpxchg.org,
aquini@redhat.com, shakeelb@google.com, llong@redhat.com,
mhocko@suse.com
Subject: Re: [PATCH v2] vm_swappiness=0 should still try to avoid swapping anon memory
Date: Mon, 9 Aug 2021 17:19:31 -0400 [thread overview]
Message-ID: <c8de174f-751e-0c2a-3fda-0896e42583e9@redhat.com> (raw)
In-Reply-To: <20210807151424.76b4ee3a@mail.inbox.lv>
On 8/7/21 2:14 AM, Alexey Avramov wrote:
>> vm_swappiness=0 should still try to avoid swapping anon memory
> Swapping with swappiness=0 depends on vm.watermark_scale_factor.
> Decrease vm.watermark_scale_factor to avoid swapping and get OOM,
> and increase vm.watermark_scale_factor to get successful swapping
> even with swappiness=0.
>
> Maybe I misunderstood you and you are solving some new problem?
The problem is new; however, the two workloads that are now running into this issue are not new (one is as old as RHEL5).
Sorry the issue was attributed to the wrong commit in my V1/V2 posting. This may have caused some confusion. The actual commit to blame is 170b04b7ae49 ("mm/workingset: prepare the workingset detection infrastructure for anon LRU"). I will be posting my V3 soon. It has a much better commit log and fixes a issue that was present in my V2.
This new change allows for challenging the anon memory at a much greater rate. I believe this is ok since it will cause less trashing; however, it may also be the case that the user wants to avoid paying the cost of writing the anon to swap, and would rather throttle the page reads (like has been the case since at least rhel5).
Hopefully my V3 clears up a lot of the questions asked, and my motivations for these changes is more clear.
Cheers!
-- Nico
prev parent reply other threads:[~2021-08-09 21:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-07 2:21 Nico Pache
2021-08-07 6:14 ` Alexey Avramov
2021-08-09 21:19 ` Nico Pache [this message]
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=c8de174f-751e-0c2a-3fda-0896e42583e9@redhat.com \
--to=npache@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=hakavlad@inbox.lv \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llong@redhat.com \
--cc=mhocko@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®