Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
MIME-Version: 1.0
References: <64899ad0bb78cde88b52abed1a5a5abbc9919998.1697632761.git.baolin.wang@linux.alibaba.com>
 <1F80D8DA-8BB5-4C7E-BC2F-030BF52931F7@nvidia.com> <87il73uos1.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <2ad721be-b81e-d279-0055-f995a8cfe180@linux.alibaba.com> <27f40fc2-806a-52a9-3697-4ed9cd7081d4@intel.com>
 <e8099116-6f78-cb4a-5036-1d7e38b63e52@linux.alibaba.com> <fd389af5-d949-43dc-9a35-d53112fe4a60@intel.com>
 <05d596f3-c59c-76c3-495e-09f8573cf438@linux.alibaba.com> <b9042fcb-05df-460f-87b8-4d7a04d3bd5e@intel.com>
 <e84f8c2d-6264-f2a3-3737-17d48a0251f8@linux.alibaba.com> <93abbbfb-27fb-4f65-883c-a6aa38c61fa0@intel.com>
 <0aaf6bf4-a327-9582-569e-2a634ce74af4@linux.alibaba.com>
In-Reply-To: <0aaf6bf4-a327-9582-569e-2a634ce74af4@linux.alibaba.com>
From:   Yosry Ahmed <yosryahmed@google.com>
Date:   Thu, 19 Oct 2023 20:45:50 -0700
Message-ID: <CAJD7tkbA0Ofvw8wQM0017DKWC3SXOT71rCnUhGkoPgQ4wOfLOA@mail.gmail.com>
Subject: Re: [PATCH] mm: migrate: record the mlocked page status to remove
 unnecessary lru drain
To:     Baolin Wang <baolin.wang@linux.alibaba.com>
Cc:     "Yin, Fengwei" <fengwei.yin@intel.com>,
        "Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
        akpm@linux-foundation.org, mgorman@techsingularity.net,
        hughd@google.com, vbabka@suse.cz, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> >>
> >> 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/