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: <2689f0de-fbb1-7ed9-6cf9-63e73bf0c119@intel.com>
Date:   Sat, 8 Jul 2023 11:31: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:     Matthew Wilcox <willy@infradead.org>
CC:     <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        <yuzhao@google.com>, <ryan.roberts@arm.com>, <shy828301@gmail.com>,
        <akpm@linux-foundation.org>, <david@redhat.com>
References: <20230707165221.4076590-1-fengwei.yin@intel.com>
 <ZKhK1Ic1KCdOLRYm@casper.infradead.org>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <ZKhK1Ic1KCdOLRYm@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?V2diaVFpTXZxMFJtcEl0S2pEN2RqbE10UTlFdlZ3M0JSODFLQzJCK2xKbWVU?=
 =?utf-8?B?SEQrb1Q0b0t6QTlFdEVuamZmaWd6NGNPUGtNeFVwMWovMmt1Z0twbXIwajdI?=
 =?utf-8?B?bjJnRzYySzFJWTdheTJzS2JBeTNMancvbk5yamwvdXp2L3ptdGk5b25tRVQ4?=
 =?utf-8?B?azNPK1dsYytzcUprR25uTHpkaHlYZ2Y3S093eEFMcUZwbXNqQXY1ck9MZit5?=
 =?utf-8?B?VmFTVkY2K0Q3RmxSZkZNdjZnZEFNVUdSMU8vdytLbjloSnJ2RTdDZDAvRm5R?=
 =?utf-8?B?U1JmcUFDMU9jdG9IaUdleHFZUGcxSUV2bitSY1c2NXd0MWw1a0FJNjE4VTR0?=
 =?utf-8?B?NklMekFuMFE1N29kQmU2RUFQU1Bodk4yZHIyZGhsZ2dUYWhCUjgvRVA0d25S?=
 =?utf-8?B?K2FXMXJ1VHR1VnZzNklXdzBOQWFqeXV5Y0V0V21UWVVhYVprTVMydG5uODRp?=
 =?utf-8?B?a3VlZWtoSzdLZjlCQzFWOTg1cUwybUNzZ3Nsa2ZiL2trV2c0eUdUeXpTSTQz?=
 =?utf-8?B?blNRQmJLc1ZzZEFGSjdubHlLSWpiS2JjS2lCc1gwZ3I4alF6MWJuTVpiU1dY?=
 =?utf-8?B?NE5iUFNJVkloWVZxWk9NQkttOWx0b0J4WVo3RU5FUHJvNDdvOTg2cE04dFYz?=
 =?utf-8?B?dHBEZ0VSUkhhdFB3U0VROXN1dC9Bc2VJSnFZQXNvOGJxMFI1Vms4amRkSXIv?=
 =?utf-8?B?U2N5VVhJM21iUXdzYmF0U2hmK2oyanlVekl1Wk5UMVM5TkN5VVNVcmd1K25v?=
 =?utf-8?B?N3Y3SWNCeGFRUkRlcS9zYWRxcngwd2hVOFVHdzNSQ1d3bzVTak9JaS9NeERL?=
 =?utf-8?B?a2w2WXduaVY2L1ZucG9TNG9xekZWSGtmZ3llSy85Tk9FaHRucXFyOW0rN0VJ?=
 =?utf-8?B?aE9aaXN5UUFKMElZYWhlS0hFZWRZRnRFQTRodURTYWdaVC9DTldKZzN1Zjdi?=
 =?utf-8?B?TXJHN29CRDhpVWpXaDl6UTE2UDI2LzRiQUlUR25FRkxWazdVSTF6QXd1aUky?=
 =?utf-8?B?UW9aM2dKY1RScTkzMDRKcDlzZktMUzBvMlZwQVFlemI0THpTQkl6c3c1MGJ5?=
 =?utf-8?B?Wm5lU0l4R3E0cnVoREpteEhiOTNtaXJvSld5dkFrQ2JuY2dGNzZ0YzdGb003?=
 =?utf-8?B?R28vVW5ib3ZmRkY4QmtQQ3lZM1FDZlI2SCswSmpNa0xBYkw4dytHWkt3Kzkz?=
 =?utf-8?B?U2NKeFhWVDZXMnJUaG9LNUw0alB2TGl3dzZhWUVCUGxTVm5FZ3FNZDJGaEJm?=
 =?utf-8?B?R2xOcDZaUE0xVXB3QWMrMEt5Tkc1WTlOVlJEOEY1b1YvMHB1b2ZPV2N1ZWhw?=
 =?utf-8?B?eXAzUkdhZCtaeVVQdUl0cy9ueUo1UFFUSVBUYUJnNTFRTUczN3ZJMzU5UVcv?=
 =?utf-8?B?QW5EU1NoOEdsTE4rYjNENHF5NUg4WndvcG0yajk5S05wREg5Wkt4UU9PZ2Jj?=
 =?utf-8?B?Q1BuL0diMTQrV3c4akxSd1lveVVKcGQ1cTlZSEZLcDFTUDBLb2VIOFRLN2lj?=
 =?utf-8?B?ZlQxcWJRa3VHa0pPa3NQU3hEY1crSlowQUxaeEE0RTBvSXZHcEhVMmlNL2FQ?=
 =?utf-8?B?WjVZMVBPMkF3eHFGc1BaQlA3VURFRytZcTVYTmxQbnhBUVJVUnR1cmNQTVhT?=
 =?utf-8?B?SGV0ZnRxaGYvOGV6MTEvRllBVEZQNE1vSFBtbksydWxIcmRIWnE0b3FBd3BG?=
 =?utf-8?B?WTJhdVJEeHVuMFBSbDY1UFFPVy9BdXVJRkhvSEpzeCtad01ORzVDUERJWWs3?=
 =?utf-8?B?SHpQT1ZuMGVVbWhKdlA2NTlsZHJmQmhjaHVuWGpVOVRBWHFwbC9mcGN1ZWVR?=
 =?utf-8?B?LytWM0lxWW1oaUVvUk1FUGovZGNuY0dXUHcvb0tFcURhZWM3aDJnOXBxK01Y?=
 =?utf-8?B?QlhTSXpNVXA0TXU0R1l1bXQ1RDZnTTRyRUhMTWxEaDVVWUpyeko5aUwvdlNO?=
 =?utf-8?B?WmJENHlCZ2lOQnc1M2U1YTIvNE0ySENRclZjMjU3aUtkU0pIdE45cVlFOHpI?=
 =?utf-8?B?ZnpiMVdzUGdlKzZxU1ZrUWh4U01rbXQ2ZS9kVXNjN25kMlpwQzg4SXRDNFdV?=
 =?utf-8?B?VHZqVUJxV0QzeTMvb1E4b1JmSXl1SkF0SEoyMDBuSFQycTFFOGE3VStQRVls?=
 =?utf-8?B?b3RMY29nOHlpTnRnQkc0UCtlQzh2YjMzN054SkFVUFNuQTJFTG1udkVRTjFk?=
 =?utf-8?B?cXc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b68f6657-69cb-4104-7101-08db7f63c5d0
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2023 03:31:10.2874
 (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: 3FghAXmGTM7I3xEcVmHmaVLLeiGLtA7WyPGFRMpO8Ln4oYEUsxcEfEsMesDAWusQPeh9gi4ZWxCfk7lizAU5VA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7589
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 1:26 AM, Matthew Wilcox wrote:
> On Sat, Jul 08, 2023 at 12:52:18AM +0800, Yin Fengwei wrote:
>> 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
> 
> This is somewhere that I think our fixation on MUST USE PMD ENTRIES
> has led us astray.  Today when the arguments to mlock() cross a folio
> boundary, we split the PMD entry but leave the folio intact.  That means
> that we continue to manage the folio as a single entry on the LRU list.
> But userspace may have no idea that we're doing this.  It may have made
> several calls to mmap() 256kB at once, they've all been coalesced into
> a single VMA and khugepaged has come along behind its back and created
> a 2MB THP.  Now userspace calls mlock() and instead of treating that as
> a hint that oops, maybe we shouldn't've done that, we do our utmost to
> preserve the 2MB folio.
> 
> I think this whole approach needs rethinking.  IMO, anonymous folios
> should not cross VMA boundaries.  Tell me why I'm wrong.

No. You are not wrong. :). That concept to keep anonymous folio not
cross VMA boundary is decent.


I tried to split the large folio when it cross VMA boundary for mlock().
As it's possible that the folio split fails, we always need to deal with
this case. I decided to postpone all large folio splitting to page
reclaim phase. The benefits we could get:
   - If the range is munlocked before page reclaim pick this folio,
     we don't need to split the folio.
   - for the system which don't have swap enabled, we don't need to
     split this kind folio.


Regards
Yin, Fengwei