linux-kernel - Re: [PATCH] mm: migrate: record the mlocked page status to remove unnecessary lru drain

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

Message-ID: <CAJD7tkYNLERnUKLu_Jsr7YAxqWNmJk7AXvOFRGSxN=1k+uq=UQ@mail.gmail.com>
Date:   Thu, 19 Oct 2023 21:02:37 -0700
From:   Yosry Ahmed <yosryahmed@...gle.com>
To:     "Yin, Fengwei" <fengwei.yin@...el.com>
Cc:     Baolin Wang <baolin.wang@...ux.alibaba.com>,
        "Huang, Ying" <ying.huang@...el.com>, Zi Yan <ziy@...dia.com>,
        akpm@...ux-foundation.org, mgorman@...hsingularity.net,
        hughd@...gle.com, vbabka@...e.cz, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: migrate: record the mlocked page status to remove
 unnecessary lru drain

On Thu, Oct 19, 2023 at 8:52 PM Yin, Fengwei <fengwei.yin@...el.com> wrote:
>
>
>
> On 10/20/2023 11:45 AM, Yosry Ahmed wrote:
> >>>>
> >>>> IMHO, that seems too hacky to me. I still prefer to rely on the migration process of the mlcock pages.
> >>>
> >>> BTW, Yosry tried to address the overlap of field lru and mlock_count:
> >>> https://lore.kernel.org/lkml/20230618065719.1363271-1-yosryahmed@google.com/
> >>> But the lore doesn't group all the patches.
> >>
> >> Thanks for the information. I'd like to review and test if this work can
> >> continue.
> >
> > The motivation for this work was reviving the unevictable LRU for the
> > memcg recharging RFC series [1]. However, that series was heavily
> > criticized. I was not intending on following up on it.
> >
> > If reworking the mlock_count is beneficial for other reasons, I am
> > happy to respin it if the work needed to make it mergeable is minimal.
> > Otherwise, I don't think I have the time to revisit (but feel free to
> > pick up the patches if you'd like).
> >
> > [1]https://lore.kernel.org/lkml/20230720070825.992023-1-yosryahmed@google.com/
>
> I believe reworking the mlock_count is focus here. If there is no overlap
> between lru and mlock_count, the whole logic of lru_add_drain() can be
> removed here.

All patches except patch 4 are for reworking the mlock_count. Once the
mlock count is reworked, reviving the unevictable LRU is actually very
simple and removes more code than it adds (see patch 4 below).

>
> And I noticed the link:
> https://lore.kernel.org/lkml/20230618065719.1363271-1-yosryahmed@google.com/
> only has cover letter and the patches didn't grouped.

That's weird, here are the patches (in order):
https://lore.kernel.org/lkml/20230618065744.1363948-1-yosryahmed@google.com/
https://lore.kernel.org/lkml/20230618065756.1364399-1-yosryahmed@google.com/
https://lore.kernel.org/lkml/20230618065809.1364900-1-yosryahmed@google.com/
https://lore.kernel.org/lkml/20230618065816.1365301-1-yosryahmed@google.com/
https://lore.kernel.org/lkml/20230618065824.1365750-1-yosryahmed@google.com/

>
>
> Regards
> Yin, Fengwei
>