linux-kernel - Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping anon memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <88f76721-3786-625f-b867-216f7904e116@redhat.com>
Date:   Tue, 10 Aug 2021 11:37:15 -0400
From:   Waiman Long <llong@...hat.com>
To:     Nico Pache <npache@...hat.com>, linux-mm@...ck.org,
        akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Cc:     hannes@...xchg.org, aquini@...hat.com, shakeelb@...gle.com,
        llong@...hat.com, mhocko@...e.com, hakavlad@...ox.lv
Subject: Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping
 anon memory

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