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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALvZod6Kv_eZcZeJOvypXe_XVzkvLDau7faiDQ2mrqV8kOqq3g@mail.gmail.com>
Date:   Fri, 6 Aug 2021 22:23:48 -0700
From:   Shakeel Butt <shakeelb@...gle.com>
To:     Nico Pache <npache@...hat.com>
Cc:     Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Rafael Aquini <aquini@...hat.com>,
        Waiman Long <longman@...hat.com>
Subject: Re: [PATCH] vm_swappiness=0 should still try to avoid swapping anon memory

On Fri, Aug 6, 2021 at 6:37 PM Nico Pache <npache@...hat.com> wrote:
>
>
> On 8/6/21 9:00 PM, Shakeel Butt wrote:
[...]
> > If you are really seeing the said behavior then why will this fix it.
> > This is just about deactivating active anon LRU. I would rather look
> > at get_scan_count() to check why swappiness = 0 is still letting the
> > kernel to scan anon LRU. BTW in cgroup v1, the memcg can overwrite
> > their swappiness which will be preferred over system vm_swappiness.
> > Did you set system level swappiness or memcg one?
>
> This fixes the issue because shrink_list() uses the may_deactivate field
> to determine if it should shrink the active list.

First, the shrink_list() will not be called for anon LRU if get_scan_count()
has decided to not scan the anon LRU.

Second, I would like to get your attention to the following comment in
get_scan_count():

"Global reclaim will swap to prevent OOM even with no swappiness"

It seems like the behavior you are seeing is actually working as intended.
You may decide to change that behavior but you will need to motivate the
change.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ