Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230802001938.3913174-1-kaleshsingh@google.com>
In-Reply-To: <20230802001938.3913174-1-kaleshsingh@google.com>
From:   Yu Zhao <yuzhao@google.com>
Date:   Tue, 1 Aug 2023 20:07:38 -0600
Message-ID: <CAOUHufbz-VHZ12b9wrCFxZ9mqVnU=Xstkoo5Ym9_tw72R1-2Gg@mail.gmail.com>
Subject: Re: [PATCH 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim
To:     Kalesh Singh <kaleshsingh@google.com>
Cc:     akpm@linux-foundation.org, surenb@google.com,
        android-mm@google.com, kernel-team@android.com,
        Charan Teja Kalla <quic_charante@quicinc.com>,
        Lecopzer Chen <lecopzer.chen@mediatek.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Aug 1, 2023 at 6:19=E2=80=AFPM Kalesh Singh <kaleshsingh@google.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 =3D sc->reclaim_idx; zone >=3D 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 <=3D 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_MOVAB=
LE
> 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 independentl=
y.
>
> [1] https://github.com/raspberrypi/linux/issues/5395
>
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
> Reported-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
> Signed-off-by: Kalesh Singh <kaleshsingh@google.com>

LGTM. But I think we need the Fixes tag and Cc stable.