linux-kernel - Re: [PATCH 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAC_TJveohqQNDT+AuoP-25Bm+=GWTZY=XWV+Q=_t=H5YujNF4g@mail.gmail.com>
Date:   Tue, 1 Aug 2023 20:00:20 -0700
From:   Kalesh Singh <kaleshsingh@...gle.com>
To:     Yu Zhao <yuzhao@...gle.com>
Cc:     akpm@...ux-foundation.org, surenb@...gle.com,
        android-mm@...gle.com, kernel-team@...roid.com,
        Charan Teja Kalla <quic_charante@...cinc.com>,
        Lecopzer Chen <lecopzer.chen@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

On Tue, Aug 1, 2023 at 7:08 PM Yu Zhao <yuzhao@...gle.com> wrote:
>
> On Tue, Aug 1, 2023 at 6:19 PM Kalesh Singh <kaleshsingh@...gle.com> 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).
> >
> > Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
> >
> > [1] https://github.com/raspberrypi/linux/issues/5395
> >
> > 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>
>
> LGTM. But I think we need the Fixes tag and Cc stable.

I've reposted the patches with fixes tag and stable cc'ed at:
https://lore.kernel.org/lkml/20230802025606.346758-1-kaleshsingh@google.com/#t

Thanks,
Kalesh