Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <fb225c52-0d46-4a67-a897-f39b5c1b5554@intel.com>
Date:   Fri, 20 Oct 2023 11:52:06 +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>,
        Baolin Wang <baolin.wang@linux.alibaba.com>
CC:     "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>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <CAJD7tkbA0Ofvw8wQM0017DKWC3SXOT71rCnUhGkoPgQ4wOfLOA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UXhBVE5DZUF1S25hS0FGR00vUHZJSm56NjZsQ3lxeHJCaWE4aHZTellnaG9m?=
 =?utf-8?B?ZzEvdjVBUExRRTdOOFNtOVVGSmVXcExOSGtPUGJEVllUdGV0bDhxdlMxajg0?=
 =?utf-8?B?Qkc1eHZTOGJQVmtQTHg1eFJsNWNhcVBQMkRnbExxclJidThqM1dKS2pkME44?=
 =?utf-8?B?SGp0OW1uOHdQVjZlOEdrYkdxT2JkZ2lkak9wYVhjUzVmVmZrWGNJY0NQYmlr?=
 =?utf-8?B?VEFEVmtaMnJQYmRxT09vYWlzRW9wbGFUMFVQNGFQWStibVQxcTZ6djZldGVG?=
 =?utf-8?B?MFRYVFBwS1NiQ0ZBL1NnRTZDMTVWRVFYRnNkR0I0bUhDcDI0b0dZR2xpTFVG?=
 =?utf-8?B?V1d5MlhDR2lOYUd0Tmg3WVNoZjJ5bWxiT0xXT3FlMDJUellHUUFJQTQ5NjFo?=
 =?utf-8?B?dGloSGdKcjFxUzBoVTNDdGFONWN2VjlMUEdkZ2JLM3ZIQnBCK3dPWU5MTEZo?=
 =?utf-8?B?RExrK0E2RXNqcE9wWmNCL2NyUHJDRUhBYXA4K0Vkc1Y5ZU9QdXlVZGZMVjdG?=
 =?utf-8?B?d3IvOGREWGYrSVd6WnpYWVVvMmJNVTBHM2h6bXVKWGZ6SG0zZnJ5R1JvV04v?=
 =?utf-8?B?MFdCUzZEZEQvalBzZFNqeVFMQ2dCZTBwNURxY281Ry9uVlZOemZTa2crRVpp?=
 =?utf-8?B?Vk0zTDM4WkE4KzhUai9jOStUSGoxVkNTT2ROSzNvY0FvWGtnaklRV05SOEpX?=
 =?utf-8?B?M1hFMHRqZ3haZXFHdWNmNEpVSjZtNkdwL1l4dFVkaC82WGpkdkVmdzRWbXEr?=
 =?utf-8?B?SnA1NGVMcFFJV1BnMng4Ti8rVitoR3NnWmh4eXA5MXdSR2hQTXN1UlpldS9M?=
 =?utf-8?B?RVU4cjhhQ1hrRFNSRDBxYlVYTWpBVUtkNE50RHVIbm1kaTh5Y3EyMVNPcElE?=
 =?utf-8?B?RG1uS0czY1Z2dVFjRjJjb2hhc2hRZTJuaWF5dFRHenVkNnZMdWszeWZZa1lD?=
 =?utf-8?B?UlhDQ2lwNDMvaW54SSsyZTJWWUNOYjJUaU8rakltL0lDeDJnMkt1Qmw1WEZS?=
 =?utf-8?B?WW9rZWVZZFgycEsyWFpIckZlbC84ZVBxTVF1WXkvdzNZTU16ak9neDdlNldP?=
 =?utf-8?B?N2lJbjNiZXRoSE5IZ3kzall2UlN1L0xaV3BtajNrcHFJN3AwczZ3NGc0K0lX?=
 =?utf-8?B?Vi9kUFVSaGhZSkpvVWZXQmNKemRyYUR5WFpGeVJtNDd2YW52akhqVDJOTCtH?=
 =?utf-8?B?MmhtZmUyUU5XOWl5RjB2NHZ6aHJrTGFsTUdIdWdTSENwZmlhbEJkeWNnN0xB?=
 =?utf-8?B?RVpUNmI0T3U2REd5cUFhOWI0N3JsN2lsVnJjM3pqQ3AyRFVmWUlpalFuQnpJ?=
 =?utf-8?B?K0dUNSsxM1pFS1Fybm5CV3VMQ2dtN2ZRdE1qaHhpMCtMcVVoaG10b2crRyti?=
 =?utf-8?B?c2R3R1p5UlRpaURXaCtIUkxlRGRJN2wyNlpDZVRPbXlacDZxQVNRTU5IR3FQ?=
 =?utf-8?B?SGQ5RkpkKzVDSmd6VlE3anB1NldTaXNnc3dJVXh0dHVkOFBVM0RHTktHUGk4?=
 =?utf-8?B?OUoxaDBZeEtnU25Da2YvMEljTnY3QjMxRHY3RnZ6bjAwYVpFbzhsQWhyTThR?=
 =?utf-8?B?NXlDUFFnaGNtbnQ2WXdwQkk2UEhlbk15SlBabkJOa0Y1V1h2TEhISUJsRWJS?=
 =?utf-8?B?bjBqZEhnYjBoSFBDbjl4MVEzWEZGVkh5b2IwWjV4SGgweEtpaUR3djBSVFRp?=
 =?utf-8?B?QzZuV3pNWEVOT1ZVOXY1Yjg1ckJVN1hqYURaUS9HclJXRTBpMm5XYlE3dG5q?=
 =?utf-8?B?WE9CUXRMcDBtbE83ZmNMdVlld0k4UmYvZHlUMU12a2pXVVRlWEVCQ0lNN1Fr?=
 =?utf-8?B?S25vblBOTmV1VU51b1gxbUVtMysrQklMTFYzaUVkVXhja0s5eFJ4M1h1cWVF?=
 =?utf-8?B?RCtjNlZKN0VjSVhFN0hnQzIrM2dxaDlzK1FpM0NxcDBJT00xUmUwK3FvbFU3?=
 =?utf-8?B?THNHbE1rR05lSCtNdmFYV3lvZSt2Rk52cE05QXBLVEJlSlRDTVU5VEMrc254?=
 =?utf-8?B?RjQ2dXpvWHI1dTRrcEVJOUxiMjZGbkFJcVdqdWZNRGdXMGY4TEN5Z0JXcWJ3?=
 =?utf-8?B?VldmMkpieXh1UjBMUTZvR0M3T0l4OXgwVnpQTmJwNWpQeHhlN29ra1BmVlov?=
 =?utf-8?B?VjJJcTFwN0tjMXh6NGVWcFlTdCtIRjlidi9oVW4yN3dRV3NsUjgyWFZicWUw?=
 =?utf-8?B?NkE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a1f2981-d190-417d-5119-08dbd11ff1e1
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2023 03:52:13.8079
 (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: quQbqz7qI0rlvK+gBLSMmVWx4Y6ds5tJN/OrBWBebuh0LCC+hOaxQUgDUS2EezKLe/tGsy5vEJYL9JoQziHTzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6510
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email
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 (howler.vger.email [0.0.0.0]); Thu, 19 Oct 2023 20:53:10 -0700 (PDT)


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.

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.


Regards
Yin, Fengwei