Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Waiman Long <llong@redhat.com>
Subject: Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping
 anon memory
To:     Nico Pache <npache@redhat.com>, linux-mm@kvack.org,
        akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Cc:     hannes@cmpxchg.org, aquini@redhat.com, shakeelb@google.com,
        llong@redhat.com, mhocko@suse.com, hakavlad@inbox.lv
References: <20210809223740.59009-1-npache@redhat.com>
Message-ID: <88f76721-3786-625f-b867-216f7904e116@redhat.com>
Date:   Tue, 10 Aug 2021 11:37:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210809223740.59009-1-npache@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 8/9/21 6:37 PM, Nico Pache wrote:
> Since commit 170b04b7ae49 ("mm/workingset: prepare the workingset detection
> infrastructure for anon LRU") and commit b91ac374346b ("mm: vmscan: enforce
> inactive:active ratio at the reclaim root") swappiness can start prematurely
> swapping anon memory. This is due to the assumption that refaulting anon should
> always allow the shrinker to target anon memory. Add a check for swappiness
> being >0 before indiscriminately targeting Anon. Before these commits
> when a user had swappiness=0 anon memory would rarely get swapped; this
> behavior has remained constant sense RHEL5. This commit keeps that behavior
Typo: "sense" -> "since"
> intact and prevents the new workingset refaulting from challenging the anon
> memory when swappiness=0.
>
> Anon can still be swapped to prevent OOM. This does not completely disable
> swapping, but rather tames the refaulting aspect of the code that allows for
> the deactivating of anon memory.
>
> We have two customer workloads that discovered this issue:
> 1) A VM claiming 95% of the hosts memory followed by file reads (never dirty)
>     which begins to challenge the anon. Refaulting the anon working set will then
>     cause the indiscriminant swapping of the anon.
>
> 2) A VM running a in-memory DB is being populated from file reads.
>     Swappiness is set to 0 or 1 to defer write I/O as much as possible. Once
>     the customer experienced low memory, swapping anon starts, with
>     little-to-no PageCache being swapped.

Pagecache are not swapped. It is discarded under memory pressure and 
written back if dirty.

Other than that, the patch looks good to me.

Cheers,
Longman