linux-kernel - Re: [PATCH v2 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

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]

Message-ID: <447aa786-b7c5-807e-1a6e-fb8369fc8a97@quicinc.com>
Date:   Wed, 2 Aug 2023 17:11:47 +0530
From:   Charan Teja Kalla <quic_charante@...cinc.com>
To:     Kalesh Singh <kaleshsingh@...gle.com>, <yuzhao@...gle.com>,
        <akpm@...ux-foundation.org>
CC:     <surenb@...gle.com>, <android-mm@...gle.com>,
        <kernel-team@...roid.com>, <stable@...r.kernel.org>,
        Lecopzer Chen <lecopzer.chen@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Suleiman Souhlal <suleiman@...gle.com>,
        Oleksandr Natalenko <oleksandr@...alenko.name>,
        "Jan Alexander Steffens (heftig)" <heftig@...hlinux.org>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        Steven Barrett <steven@...uorix.net>,
        Brian Geffon <bgeffon@...gle.com>,
        Barry Song <baohua@...nel.org>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v2 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

Thanks Kalesh for taking this to upstream.

On 8/2/2023 8:26 AM, Kalesh Singh wrote:
> MGLRU has a LRU list for each zone for each type (anon/file) in each
> generation:
> 
> 	long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> The min_seq (oldest generation) can progress independently for each
> type but the max_seq (youngest generation) is shared for both anon and
> file. This is to maintain a common frame of reference.
> 
> In order for eviction to advance the min_seq of a type, all the per-zone
> lists in the oldest generation of that type must be empty.
> 
> The eviction logic only considers pages from eligible zones for
> eviction or promotion.
> 
>     scan_folios() {
> 	...
> 	for (zone = sc->reclaim_idx; zone >= 0; zone--)  {
> 	    ...
> 	    sort_folio(); 	// Promote
> 	    ...
> 	    isolate_folio(); 	// Evict
> 	}
> 	...
>     }
> 
> Consider the system has the movable zone configured and default 4
> generations. The current state of the system is as shown below
> (only illustrating one type for simplicity):
> 
> Type: ANON
> 
> 	Zone    DMA32     Normal    Movable    Device
> 
> 	Gen 0       0          0        4GB         0
> 
> 	Gen 1       0        1GB        1MB         0
> 
> 	Gen 2     1MB        4GB        1MB         0
> 
> 	Gen 3     1MB        1MB        1MB         0
> 
> Now consider there is a GFP_KERNEL allocation request (eligible zone
> index <= Normal), evict_folios() will return without doing any work
> since there are no pages to scan in the eligible zones of the oldest
> generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE
> allocation request; which may not happen soon if there is a lot of free
> memory in the movable zone. This can lead to OOM kills, although there
> is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to
> reclaim.
> 
> This issue is not seen in the conventional active/inactive LRU since
> there are no per-zone lists.
> 
> If there are no (not enough) folios to scan in the eligible zones, move
> folios from ineligible zone (zone_index > reclaim_index) to the next
> generation. This allows for the progression of min_seq and reclaiming
> from the next generation (Gen 1).
> 
As discussing offline, I think this can make system to spend too much
time in scan_folios() in moving the pages from Gen-0 to Gen-1 of the
other zone which can result into OOM is not active when necessary.

> Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
> 
> [1] https://github.com/raspberrypi/linux/issues/5395
> 
> Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
> Cc: stable@...r.kernel.org
> Cc: Yu Zhao <yuzhao@...gle.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Reported-by: Charan Teja Kalla <quic_charante@...cinc.com>
> Reported-by: Lecopzer Chen <lecopzer.chen@...iatek.com>
> Signed-off-by: Kalesh Singh <kaleshsingh@...gle.com>

We tested this patch on our systems for couple of weeks and aggressive
OOM is not observed which otherwise is easily reproducible.

Tested-by: Charan Teja Kalla <quic_charante@...cinc.com>