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: <362ac9b2-566f-f942-e98a-196ce38b6003@intel.com>
Date:   Sat, 8 Jul 2023 13:35:01 +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:     Yu Zhao <yuzhao@google.com>
CC:     <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        <ryan.roberts@arm.com>, <shy828301@gmail.com>,
        <akpm@linux-foundation.org>, <willy@infradead.org>,
        <david@redhat.com>
References: <20230707165221.4076590-1-fengwei.yin@intel.com>
 <CAOUHufY++PUYp3qcmX2rK5AQrgu9rPT3tYOpj=44BX4K67Znrw@mail.gmail.com>
 <ca1df2b0-3a36-2762-f20e-b4a235087c9d@intel.com>
 <CAOUHufY0=EW65tD01mm6ha75XWjcc43aGVuSJ8AfPc+dDLH6ZA@mail.gmail.com>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <CAOUHufY0=EW65tD01mm6ha75XWjcc43aGVuSJ8AfPc+dDLH6ZA@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?R2JQaEdEbkZ4Zlp6OXMyTnBPT0laUTVNSlJjMEJ2SXUvQ2tsNk1LWm40SzFx?=
 =?utf-8?B?YUFoY1lxU1U5S0lvbUxyUFlhTDRsNXRMbFNGUEhRd01WMWQ2bks4eitBdi9M?=
 =?utf-8?B?d1ZmQjU4N08rNFNUbGFoQ0pHZlZJbi93Nk5EdEhXRDZXSXlSd1ZmeDBDc3hk?=
 =?utf-8?B?THB0SmMrK0EyVzFjM01XMElTYmp5Wkp1QkFYcGFaWjZ3NDY5UkJVRXR5U1ZV?=
 =?utf-8?B?OC9zU0ZQQmtaa1BmVnZHTVhXWVRvN0NZRzIxZFhKdklIaWJmZFN6R2pVdUlB?=
 =?utf-8?B?SGhLTW94OHBQZVJnTmh2RnEzUzNLR1lFR1Z1Q0plb29nUktZaWpGbG8yWE1O?=
 =?utf-8?B?Wm1WZXMxclROaW92eGVwcjNlRDA3Q05ha1N6cjJuK3RycHZlTmJISEVBaW1w?=
 =?utf-8?B?ZlROblJJdk83NGcxRFUrWG5TVkJkbFFLNTVYZDA2cmRtVFFoQ3FEVkFYMGRW?=
 =?utf-8?B?dGF0U3FIdjBJNHhKeXAvMUJJalZEcGV5dEk4UlhWKzFIbGYrQ3ByanVyRkVv?=
 =?utf-8?B?NThKRlJkQXJHRUFPN1RyUENnQzNRTTlXSkR4eW5MdWxEbGNMdWJVUTFuL2dk?=
 =?utf-8?B?MzIzb3U0QUEzMzUrcUJQRVlUbFErNmZzRXJxK3lCNXRjc1NyWUNQT0VBK3U3?=
 =?utf-8?B?UkY1RDdhVGVvTTZrd3JYYmZNWThsR1ZYa2gva3dvdTB5WUhodkxlekpKd29G?=
 =?utf-8?B?U3NFREZubHNQTC91aGtWWUtzdTJ0MGVRaFNKRDBiRzZxMHFqREgrLzZpUjRp?=
 =?utf-8?B?VEVrTU90ZVYxaUhVQnZWNVNpeS9UL3pVSUJhd3JRUEpiT29tNHZoVGs3cXNR?=
 =?utf-8?B?MlJJSXkyYXE2azdBN0hkV1NJV1BMMFBzKzJiTURqYmluL3pKQk5FZy9YTWxW?=
 =?utf-8?B?R2M0Q3BmM0NvNmwvVFEwOUVqeWhobTR3OTRtSUhhUVArL2YxNVJUN1ZmdTlO?=
 =?utf-8?B?ZFZDYnoxdUtmKzFwNzI3cjRHM1ZvL2xoaTFTbTcwbVhKSUJQR0w3TGF5WDhi?=
 =?utf-8?B?L0VjTFpQaXM0Z2VrUnhhYUpCSHcxaXJSMEhxdzQvaHYzaUVIYmlDYXp1RDI3?=
 =?utf-8?B?ZWluQytHcmRKYit6UVZ1VjlZSk5OeWRQSUllM1N0OWUzWlA2NEhaVWIxdmdH?=
 =?utf-8?B?bVY4em9vekowTFprSVppbmZUS2NhNVdLM3NxRWZuZ1o3VStmMUxwMFRHQzBs?=
 =?utf-8?B?OFpDd0pzRVBzZnNUUHBnY0F2cEVpWU1CTnZJZjcyZDFqZGxCSjNUd0p5eUM1?=
 =?utf-8?B?K3B6bFlqdkdNMGMxbDFqU2ZVcnl3RFFSb3BoMEN6eEUremtKTHJ6VFZvang5?=
 =?utf-8?B?Vjdma3ZXNFNvYi91R3pQOGkvQUw1WnlNSDFnV2lscEpLNFFUSHdra2dvV3VN?=
 =?utf-8?B?eGo4K3Vmb2xqZ0IwL2RyblJ4RllUVDdJUUpsSFpoMUV0MVY3ZEpTWVNPTm9m?=
 =?utf-8?B?VjJjOGF0elhqYUQrRHgvVVlTd3RyazloeTI1ZVRhWWRaSUtkaUY4YUxsakpo?=
 =?utf-8?B?aGhib3pVSHhkNXdsSUtQRk1FYVEvczdBOGMvOXcrM3FPbnFjNjlBWVduOUl5?=
 =?utf-8?B?QUJudXprdi8rMUJYNUQvRFRlK09jb0VnODRYdHNGNm5yekZVSHdhSE1BaDda?=
 =?utf-8?B?eUtMYm1sa0FDc0JDZ2xnL1YwUTBKVTIzUTUrV1BuaEphNWUvNzkra0RJUFYz?=
 =?utf-8?B?N3hPTGdjcHlYNG9pcld0akVYTmFFUGh6WGF0N3JmcHk0OVJGZkcxTy9EMU92?=
 =?utf-8?B?MzNLbVVxekVtR0RIc0V2bHZ2VkNvTS92WUhYMXRSZFhQWWhyMXZRQm1SOHZW?=
 =?utf-8?B?WWxKbThEOE9ITFBEMjBQOWkvQTFNZWxuUi81aThjbXBqWi9lRjBlV3E3ZVJY?=
 =?utf-8?B?ZFpIK0tEaU1xR05rNnU2akRYUGQvYlkzK3lYdWF3dlhjRHlXOXFsVXphQ2ZE?=
 =?utf-8?B?Z1VOOW1kVU5RMVhEMGlGWDhBM0hIdnd3dS84MUpKaFJrc3hHWkt5YkFra3Jy?=
 =?utf-8?B?dmJ6R3pLTjVNMCtodlRaRzgvbENUdzc2QU5UUW9Zd3haTXVtSzQxUnc2eXlV?=
 =?utf-8?B?MzdXQkt3WFN3cDFpaFMxejJnREZGZ25GZmMxd2M0Qk4xWkRnQjVKVHNSNWVH?=
 =?utf-8?B?WXN5MHhxNTBLWVNwYkk5Nmg0SVFsZHc4RjNXVEhoeFMyOENsVkN3cER5cW81?=
 =?utf-8?B?L1E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a83db06e-ff48-4bbf-3598-08db7f7517a6
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2023 05:35:08.8724
 (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: 1jrFB6aE8AtgeckY0eO86I8+eNaWkws70TG/Adnq3zXA6TJMLu7wcpJwyxL6rK0X3RiBPLEmoqZnJH3vUo37bA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7651
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,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 1:06 PM, Yu Zhao wrote:
> On Fri, Jul 7, 2023 at 11:01 PM Yin, Fengwei <fengwei.yin@intel.com> wrote:
>>
>>
>>
>> On 7/8/2023 12:45 PM, Yu Zhao wrote:
>>> On Fri, Jul 7, 2023 at 10:52 AM Yin Fengwei <fengwei.yin@intel.com> wrote:
>>>>
>>>> Yu mentioned at [1] about the mlock() can't be applied to large folio.
>>>>
>>>> I leant the related code and here is my understanding:
>>>> - For RLIMIT_MEMLOCK related, there is no problem. Becuase the
>>>>   RLIMIT_MEMLOCK statistics is not related underneath page. That means
>>>>   underneath page mlock or munlock doesn't impact the RLIMIT_MEMLOCK
>>>>   statistics collection which is always correct.
>>>>
>>>> - For keeping the page in RAM, there is no problem either. At least,
>>>>   during try_to_unmap_one(), once detect the VMA has VM_LOCKED bit
>>>>   set in vm_flags, the folio will be kept whatever the folio is
>>>>   mlocked or not.
>>>>
>>>> So the function of mlock for large folio works. But it's not optimized
>>>> because the page reclaim needs scan these large folio and may split
>>>> them.
>>>>
>>>> This series identified the large folio for mlock to two types:
>>>>   - The large folio is in VM_LOCKED VMA range
>>>>   - The large folio cross VM_LOCKED VMA boundary
>>>>
>>>> For the first type, we mlock large folio so page relcaim will skip it.
>>>> For the second type, we don't mlock large folio. It's allowed to be
>>>> picked by page reclaim and be split. So the pages not in VM_LOCKED VMA
>>>> range are allowed to be reclaimed/released.
>>>
>>> This is a sound design, which is also what I have in mind. I see the
>>> rationales are being spelled out in this thread, and hopefully
>>> everyone can be convinced.
>>>
>>>> patch1 introduce API to check whether large folio is in VMA range.
>>>> patch2 make page reclaim/mlock_vma_folio/munlock_vma_folio support
>>>> large folio mlock/munlock.
>>>> patch3 make mlock/munlock syscall support large folio.
>>>
>>> Could you tidy up the last patch a little bit? E.g., Saying "mlock the
>>> 4K folio" is obviously not the best idea.
>>>
>>> And if it's possible, make the loop just look like before, i.e.,
>>>
>>>   if (!can_mlock_entire_folio())
>>>     continue;
>>>   if (vma->vm_flags & VM_LOCKED)
>>>     mlock_folio_range();
>>>   else
>>>     munlock_folio_range();
>> This can make large folio mlocked() even user space call munlock()
>> to the range. Considering following case:
>>   1. mlock() 64K range and underneath 64K large folio is mlocked().
>>   2. mprotect the first 32K range to different prot and triggers
>>      VMA split.
>>   3. munlock() 64K range. As 64K large folio doesn't in these two
>>      new VMAs range, it will not be munlocked() and only can be
>>      reclaimed after it's unmapped from two VMAs instead of after
>>      the range is munlocked().
> 
> I understand. I'm asking to factor the code, not to change the logic.
Oh. Sorry. I miss-understood the code piece you showed. Will address
this in coming version. Thanks.


Regards
Yin, Fengwei