Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <3a14bd9e-0b90-4a89-90b3-4e571ab1a51d@intel.com>
Date:   Fri, 20 Oct 2023 12:04:07 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] mm: migrate: record the mlocked page status to remove
 unnecessary lru drain
Content-Language: en-US
To:     Yosry Ahmed <yosryahmed@google.com>
CC:     Baolin Wang <baolin.wang@linux.alibaba.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>
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>
 <CAJD7tkbA0Ofvw8wQM0017DKWC3SXOT71rCnUhGkoPgQ4wOfLOA@mail.gmail.com>
 <fb225c52-0d46-4a67-a897-f39b5c1b5554@intel.com>
 <CAJD7tkYNLERnUKLu_Jsr7YAxqWNmJk7AXvOFRGSxN=1k+uq=UQ@mail.gmail.com>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <CAJD7tkYNLERnUKLu_Jsr7YAxqWNmJk7AXvOFRGSxN=1k+uq=UQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aU9ob0gwalZpYkJuQVdOcVpuOUxUMi82MHpKSi9BbkswQXcyNDFLNGtaT0Zy?=
 =?utf-8?B?WXM2WjZ3Zmk0WTVpWnFqbzAwa1ZBYlF2MW5rSTBvL3VxaVVXV3J2V3RScFVh?=
 =?utf-8?B?OWd5emZTZWtwUGk2aURRUUlQZHY2RWV0a2pzMm84NnZlUFU1cnJaZVRQdXY5?=
 =?utf-8?B?SS9ySE1FczFHVWQrMk5YKytydUFKeFI1Zk5RbytveFRmRGlwM1hrMlZGWGM5?=
 =?utf-8?B?ZytKT1NqMVVMQzlYd1NFdzl1eEpScFh3dWRKVElGbXV5ckdzZElHKzBWd1dz?=
 =?utf-8?B?WkYzVzF0VVRNL2FlbDRkMDl1MkMxdnh0SnhmUzlsSVJ4U0ZiUzdZZVB3bzRP?=
 =?utf-8?B?WVg3WWVnZWV0NG0rVUZtcVM4NDYweDl0Mm5LQ0tsSEd0a0ZUdlRCaXRZYTJm?=
 =?utf-8?B?alh6dlQyaDE4RGlYaWtSVlkxektwVWJsTU44dXVmWERjR3hYNzIxamNTeGtN?=
 =?utf-8?B?WXpXb3BwQTBqaXhBclU5NGhkTCs5RDFNRGcvV2FxSmdxYXNoak44VVRJMmM3?=
 =?utf-8?B?TFJOQTVZMC9KVjY2Q2dFalp3ZHM4dkZ5VWVZcHMxRkJ6NTl4bUdYMUxmWDV0?=
 =?utf-8?B?clFVYXpHSWoySTI0MHpBNm9FNFJERmhvYkc5Y1FIV1RrZ2ZIVjZRQzUvaEVZ?=
 =?utf-8?B?MlgxaFpnZGkxKzRONDhCVG9nTThzU1lCd2RuT1laUWdWTU1VU05zMTlIdjRT?=
 =?utf-8?B?OXlLamZvUFNaY3d1VWFROXdoTXJIaHRrS2lxbnc1RXNFSWVRWFZ6SG5iMU94?=
 =?utf-8?B?d1RxbnRFTm1mSitQSFRTQVhCNEpwMTkyZlBVM0hMWWtmcDIydURnYjhvSW9u?=
 =?utf-8?B?d1NIREoxaXc5NmdHcHlYUlRwV05wdjlzVmxnb1d1K1IvSVM2ZUlkcVg0TjJI?=
 =?utf-8?B?cm9RdXJWSU1VUmVQRzMwbFhML3FDTHJFVjQ1QlNIOGMzY3hTYzkySUNhcSt0?=
 =?utf-8?B?OFY1cTl0eTQzVWZ2aEVxUk1DYXVUdUp5L1I0RTk2WVlkVE1leFBJdFkyaXhF?=
 =?utf-8?B?SFFNVHZISVpBMnRLWElxZmhPWURCQzU2MXNYcjN2Y1FzdVpxUHZYcmVuaklR?=
 =?utf-8?B?UDJIY1Q4bTlUVWpodVE3b3hXaWJNaU5pRFNYaEhqNEtEVDg5YmdiWG1zc2ov?=
 =?utf-8?B?aHBESEthUzcwTzRFZnRLcTZpL0pscUpTNUtIOXYvd2tEeDc2S1ZPeUg0c3Vm?=
 =?utf-8?B?Ui95V1VMSFRia1RXcTVwT2ltc3JYTUd6Z1NaK2wzUTVObktTVEJHK0dZL0Q2?=
 =?utf-8?B?SFJIMDFjdU5KcVhyZVlUbE9FOHNsREdvNGlLY05GQU9vbGUzaDdieGxVaEZI?=
 =?utf-8?B?UUlWOGR3bHpmSmE4ZG00WnU1bGI4NTRWNkpud3VGMTIzNEYra0RoTlR6aFdP?=
 =?utf-8?B?UnYrdFZzUmxacTR1cjJRZWZ6UjNLNmJ3Umh3TitoNm9wMFRWQ0lzMU00SVR0?=
 =?utf-8?B?aGRkMVJkeWY1YUZpaHREOHoybmRXeGhXRWFYOUVBZkczZXU5QmJlOFU3ZjRv?=
 =?utf-8?B?b3A1LzdRZTRZeitPWTlhZGJCRmFBSkh4Ulo2UnN6K2ZwTk43dFJ4VU1oWkI3?=
 =?utf-8?B?R2dFbXluSDVCK0twaTNYUGdrbkY1UGxzUFlFZEFsTEw2eWdQdVl3WWlVUGlO?=
 =?utf-8?B?U2pTK3Fkd0huZkdNOWRWTlozbkZUN2VVY1cwSFlpSWVkZXpqWnMydFRrdjJj?=
 =?utf-8?B?dHp4MzB2Ny9yUkxBTXpTbjRlSFBORGRGaExqTnRQL1ZzNk5QVnZTQ0kyK0Nl?=
 =?utf-8?B?YmlaaU5IZ1dUUHVUMmRqeDgyOWJmaEVRVVAvbGduYnlLaXdtcE50Q0hoM3NY?=
 =?utf-8?B?SDR2N29CT3lxSS91Y3BHQnBHWXVqTncyajkzdGRZQzIxWG1pUm8zSXRBVG1n?=
 =?utf-8?B?WVgzbVF2UCtFeW1IWnIxcXIyRjQyNVJ6NXlEY05WdlplZ1B3UmkvZWE0QWFS?=
 =?utf-8?B?WEI0YUNHdUZwZERPcHkwTjFOd3pTazA4RlM0bXFQNHRnTHl1Zk9HTkwzUDFT?=
 =?utf-8?B?dnc1VU0zZEN0dEdRYzVMMFNMWkNHM0F2OWhEdk92Y2NOUHE4K3gwWGg4YUoz?=
 =?utf-8?B?NlNkZWNnaVJEWHAwMVd6YzNMRUs1ck5sdURrZ3JCZnhxTTFUbExEd0JuRzZy?=
 =?utf-8?B?WFZXVVFuZW9SWW5qOFhPblJqbjZPbldia1Mva2pVd3pqOTM4bTA0M1BjMXg0?=
 =?utf-8?B?bEE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 129ef9e9-d25e-44aa-93ed-08dbd1219f0d
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2023 04:04:13.8226
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xsWtNSPZlzDafCFW8nEngVbOA0nU8n+wy9uVRPsVnuG/kpraZBX48g44cZNeCF0jUfiS5PgMWKMCDefo7A4JfQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB7968
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 19 Oct 2023 21:04:24 -0700 (PDT)


On 10/20/2023 12:02 PM, Yosry Ahmed wrote:
> On Thu, Oct 19, 2023 at 8:52 PM Yin, Fengwei <fengwei.yin@intel.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/
Thanks a lot.

Regards
Yin, Fengwei

> 
>>
>>
>> Regards
>> Yin, Fengwei
>>