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;
Message-ID: <afd3a7bf-cd45-9c59-a853-d49d82ee87da@intel.com>
Date:   Sat, 8 Jul 2023 12:36:22 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.12.0
Subject: Re: [RFC PATCH 0/3] support large folio for mlock
Content-Language: en-US
To:     Matthew Wilcox <willy@infradead.org>
CC:     David Hildenbrand <david@redhat.com>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, <yuzhao@google.com>,
        <ryan.roberts@arm.com>, <shy828301@gmail.com>,
        <akpm@linux-foundation.org>
References: <20230707165221.4076590-1-fengwei.yin@intel.com>
 <ZKhK1Ic1KCdOLRYm@casper.infradead.org>
 <4bb39d6e-a324-0d85-7d44-8e8a37a1cfec@redhat.com>
 <ZKhiGLpIWi5Z2WnY@casper.infradead.org>
 <436cd29f-44a6-7636-5015-377051942137@intel.com>
 <ZKjfwYWh/n/LbTZv@casper.infradead.org>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <ZKjfwYWh/n/LbTZv@casper.infradead.org>
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?UXVFaHNFdm5LY1dpRGZUVnNRWUdhUlBzRDBQbXFUNVhpcjluT29qbVlEcng1?=
 =?utf-8?B?UUFVbHo5TnZDeTZaWG0yUUtvYi9JOE1IUWlINGR5U3Y1N3U3ZmRVMllCMWJ5?=
 =?utf-8?B?MmRXZFpHbFNyNEZqWGU0Q1ZsT2pQbW8yTFdEb3RBVllwWTVISWVSV0t3MUo1?=
 =?utf-8?B?TVMybU1WTkFqbUJwRmY5Z0JBNkg4RE9zcml6bjVORXQ3U3FCR1VPTFZubFFL?=
 =?utf-8?B?WWVsK3A4dlByNHlaT0VwcFpjTFU5ajNkUmNTb3RMNFJCMjJzNW9NNno0R3lT?=
 =?utf-8?B?NzE5NWk5eFJoWlRhYWRrNVpOLzEybHh5Y2FFc3N0bXgrbWZTR3E3UGVFZzJZ?=
 =?utf-8?B?SHhubTZJZzBXZG1rbXVLRk9laEFybS9uT00wdlhNaXhta3FSWUwzajB5dmNS?=
 =?utf-8?B?SElEYVFGQXNJanEwelJuSnpQM2dmNnN4aGd2OHB5aXRuZlM3d2QzNG1TRUNS?=
 =?utf-8?B?Qk9YbVBDdDNNOVl0dDNyTnNsOFVHTXdVMjIxWVVpNTRWbUJYZk9QWi8zZ1du?=
 =?utf-8?B?T2k3ZWc1dkwzT0FWcHlOMmNHNTc5ZmJFbFNOdDd5czZSQUI2UE56MGdhTHlx?=
 =?utf-8?B?UGR6TmtyWFhpNnFBaHFRSmtQbnBaMkV5N0FPbW1PbzdXcWNzZWFBVWovbFll?=
 =?utf-8?B?K2t4VVUzcjgrbm84OStRYjE0WHlCTmlUSGxMYStqOGY2RXB1RndBVC9odVBi?=
 =?utf-8?B?Ti9oT1c4aExURGdtaFg4L0tiek5Ia1ZMSTMxTXlzRGxpakpQY0VPQkFoVm1r?=
 =?utf-8?B?Znl1ZzdTaTJ2NHRZTDluUXgyem0xWkpUbUlHWW52aEY3WFNaek1HY2hEL2Nk?=
 =?utf-8?B?VVdhTGI4WWY3dnAvR1ZZdlJ1UFhvNllNUForczFRS0EvOVAxQ2EwbTJoZ2pp?=
 =?utf-8?B?dkdYc2poZzV2OGcySVZuNlozQXNKQ2dlbi9HUUZvc0h2a0Q2Q01VaEFXS3N5?=
 =?utf-8?B?bnJxeVFudWNWclk2NytWa21TVnYzMURWNlNDYldvYjFycGxxaUgxY2ttTThV?=
 =?utf-8?B?aFg2TE9FOXRzaENPajhuRkRjckI5bzQwR0kxbkgzaGgvcXgyYXBidDBoUFg5?=
 =?utf-8?B?V2o3T2ZCV1pTc1d3ZVNRYWg1MlVLbnVuYVlvcWRJZVBDKytQNGxwTTd0ZXpP?=
 =?utf-8?B?YytEd1IrUzM5WVZSRk5kdnhTU3hCKzJrVVJSV3NNbTBURmlIVWVUdXp6Y3RG?=
 =?utf-8?B?Mjc0QndlOElSYlNOS3Z2VzR5TmRJSzgrTjJUbmg4cnI3RTdYR2s4Q2pRckRY?=
 =?utf-8?B?WC9KRFZrbExzZXdZVFV2RWFNMVNoZi8vVEdrejU4WXVYRXk3UFBVYUhEYWMz?=
 =?utf-8?B?Y0tNU2Zkek8zYUJWYTJyS2ptdTArRElubHgrYkRIckd4bkFIMC96VVNXK09r?=
 =?utf-8?B?Qm5rcU1wWEEza20vb1p3WlBDVnJNOWlqWEVhaDRnakd2cjZHMWUvN1kxejNo?=
 =?utf-8?B?ODV2V0JGMSszWlJaY2Ira0FqQ1BNcmNEa1ZjcDh3eVRGbVVBanhrNFZyTVgw?=
 =?utf-8?B?cWVKTkYxRXY1MWFJNzZDcVgvOWZyMTljOFY5UVpmeUZKRzJ5cUQwZUwrTThv?=
 =?utf-8?B?V2Uxd0E1RURpZHVKaHQxM1Q1eEpoMnd6cXJmcWd2cC9vdmV2ZTJ3VDJPeldH?=
 =?utf-8?B?K3pmaElpZmF5Kzlpa2h2TGNKNkVIbUhBSzJiTUV2N040UTlPRDNWdlVPa0JX?=
 =?utf-8?B?VDV3SFN1M3VqKzdVNjZLc1RveUN5MEYzeXdWYTc2OW45RlRucTYycEIwZGk2?=
 =?utf-8?B?UXRXa3J0TVN2TDRqdkRCSkFicmhVWFBkOEZRalNzajIvbXBjZE94TTh2S3No?=
 =?utf-8?B?U0MzNzVTVmhVNitwT3B6SzduR0lOcytZV01GY2RLdTBKcjc1UWxNN05pWXVC?=
 =?utf-8?B?UW1wNkxYMTB3R1VnY2hQMVFPZ05ZdXUyTll5V1F6MWRNR2w4V3d0OHpVN05B?=
 =?utf-8?B?YmtPL0pCS2Y4K3ZabG5SUXQ3T0g3SDVSTTcvTUozVE5WN3JjVE13SDhXV0xl?=
 =?utf-8?B?OXRBeG5Za3hPTlhBTHc3U2NBNytxSWJXd3lVamRid1JMWWNab005QXJ1YzE1?=
 =?utf-8?B?V1RHc2pFRmFtRHBDQ01ONzIrRXFQT0VWUnhuTTVIaG11SmxHMFUvcjF2MEJW?=
 =?utf-8?B?dGJBZEQxWjU5c2ZoUFVid1RCOU5sREtIWk9lRFNGQXR4a1JPU3pYUXQ0aVZj?=
 =?utf-8?B?c2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 70cc1660-ab49-48d1-2276-08db7f6ce673
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2023 04:36:30.7347
 (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: b9hqpDB46fosg6BrMaGRiAP2hF8hgDmuSPk4QmnTaYUw8gtE19xOgV9vHSeUWkQtsB9fD5c2BywcxjRbUkZrFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5121
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED 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


On 7/8/2023 12:02 PM, Matthew Wilcox wrote:
> On Sat, Jul 08, 2023 at 11:52:23AM +0800, Yin, Fengwei wrote:
>>> Oh, I agree, there are always going to be circumstances where we realise
>>> we've made a bad decision and can't (easily) undo it.  Unless we have a
>>> per-page pincount, and I Would Rather Not Do That.  But we should _try_
>>> to do that because it's the right model -- that's what I meant by "Tell
>>> me why I'm wrong"; what scenarios do we have where a user temporarilly
>>> mlocks (or mprotects or ...) a range of memory, but wants that memory
>>> to be aged in the LRU exactly the same way as the adjacent memory that
>>> wasn't mprotected?
>> for manpage of mlock():
>>        mlock(),  mlock2(), and mlockall() lock part or all of the calling process's virtual address space into RAM, preventing that memory
>>        from being paged to the swap area.
>>
>> So my understanding is it's OK to let the memory mlocked to be aged with
>> the adjacent memory which is not mlocked. Just make sure they are not
>> paged out to swap.
> 
> Right, it doesn't break anything; it's just a similar problem to
> internal fragmentation.  The pages of the folio which aren't mlocked
> will also be locked in RAM and never paged out.
This patchset doesn't mlock the large folio cross VMA boundary. So page
reclaim can pick the large folio and split it. Then the pages out of
VM_LOCKED VMA range will be paged out. Or did I miss something here?

> 
>> One question for implementation detail:
>>   If the large folio cross VMA boundary can not be split, how do we
>>   deal with this case? Retry in syscall till it's split successfully?
>>   Or return error (and what ERRORS should we choose) to user space?
> 
> I would be tempted to allocate memory & copy to the new mlocked VMA.
> The old folio will go on the deferred_list and be split later, or its
> valid parts will be written to swap and then it can be freed.

OK. This can be common operations for any case that splitting VMA triggers
large folio splitting but splitting fails.


Regards
Yin, Fengwei