linux-kernel - Re: [PATCH v6 6/9] mm: multigenerational lru: aging

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] [day] [month] [year] [list]

Date:   Fri, 14 Jan 2022 02:00:55 +0900
From:   Alexey Avramov <hakavlad0@...nam.cz>
To:     mhocko@...e.com
Cc:     Hi-Angel@...dex.ru, Michael@...haellarabel.com, ak@...ux.intel.com,
        akpm@...ux-foundation.org, axboe@...nel.dk,
        catalin.marinas@....com, corbet@....net,
        dave.hansen@...ux.intel.com, hakavlad@...ox.lv, hannes@...xchg.org,
        hdanton@...a.com, jsbarnes@...gle.com,
        linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, mgorman@...e.de,
        page-reclaim@...gle.com, riel@...riel.com,
        torvalds@...ux-foundation.org, vbabka@...e.cz, will@...nel.org,
        willy@...radead.org, x86@...nel.org, ying.huang@...el.com,
        yuzhao@...gle.com
Subject: Re: [PATCH v6 6/9] mm: multigenerational lru: aging

> But the later one is more complex and a proper
> handling really depends on the particular workload

That is why I advocate the introduction of new tunables.

> There are workloads which prefer a temporary trashing over its working
> set during a peak memory demand rather than an OOM kill

OK, for such cases, the OOM handles can be set to 0.
It can even be the default value.

> On the other side workloads that are
> latency sensitive

I daresay that this is the case with most workloads.
An internet server that falls into thrashing is a dead server.

> no simple solution can be applied to the whole

There are several solutions and they can be taken into the kernel
at the same time, they all work:
- min_ttl_ms + MGLRU
- vm.min_filelist_kbytes-like knobs
- PSI-based solutions.

> For the most steady trashing situations I have
> seen the userspace with mlocked memory and the code can make a forward
> progress and mediate the situation.

I still don't see a problem in making all the kernel-space solutions
in the kernel.