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: <b995e802-1500-6930-79d0-8cc4bfe89589@intel.com>
Date:   Wed, 19 Jul 2023 07:47:38 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.11.0
Subject: Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle
 large folio
To:     Yosry Ahmed <yosryahmed@google.com>
CC:     Yu Zhao <yuzhao@google.com>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, <akpm@linux-foundation.org>,
        <willy@infradead.org>, <david@redhat.com>, <ryan.roberts@arm.com>,
        <shy828301@gmail.com>
References: <20230712060144.3006358-1-fengwei.yin@intel.com>
 <20230712060144.3006358-4-fengwei.yin@intel.com>
 <CAOUHufYef--8MxFettL6fOGjVx2vyZHZQU6EEaTCoW0XBvuC8Q@mail.gmail.com>
 <CAOUHufZ6=9P_=CAOQyw0xw-3q707q-1FVV09dBNDC-hpcpj2Pg@mail.gmail.com>
 <40cbc39e-5179-c2f4-3cea-0a98395aaff1@intel.com>
 <CAOUHufZHyEvU-c2O6B6stM_QVMxc22zV4Szn52myYqjdZvptUA@mail.gmail.com>
 <16844254-7248-f557-b1eb-b8b102c877a2@intel.com>
 <CAJD7tkYAkVOE2caqEj_hTmm47Kex451prBQ1wKTRUiOwnDcwNA@mail.gmail.com>
Content-Language: en-US
From:   Yin Fengwei <fengwei.yin@intel.com>
In-Reply-To: <CAJD7tkYAkVOE2caqEj_hTmm47Kex451prBQ1wKTRUiOwnDcwNA@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?UzBmK21pdjZwZmpsUWliVjVRa2ZFUFFvRzFIOXpzNkFRSEJIOHl0ckZJOEUr?=
 =?utf-8?B?ZmxJak9IS3lSNXF0LzkvVFZzWFJqNys4MGhzMUdsUDI5Q0tENGFJVXMwZTlu?=
 =?utf-8?B?b0FLQWtMSnIvY2cyaWIrS1gyN0JqZ1BzVzhnL0JVbVdrTjE1TFVJcFFJekFK?=
 =?utf-8?B?cG5zaTVhcm5ORm9KQzhXUU5qbGprYVN0WWFXc1Zid2k5TGhTeVpMbjBpYVZm?=
 =?utf-8?B?cUhwbG5lNFRsN2pya04zUXZibUg3ZUR6ejQ3T1dCNVRlcldENWxHenFBaHl3?=
 =?utf-8?B?K1hIeHRHbGpjNkZranVVaU82amQxQ2dicEpMaHBNdUFScnVqYjlSdlE2b0RK?=
 =?utf-8?B?a2VEYWN3WTlKSXFQa1ZQQXV6bFMrUVpuaDZYMDY0Mm9OczF5TnRoNjQ4VmZX?=
 =?utf-8?B?N3Bwb1E0K3RzNmZZQ1RuTWhaN2RzbEcyT0VwbENtSXNmdXJhSzBDNmVYdWZp?=
 =?utf-8?B?dngzZ3NWRVV2eFczWU9xYTNVWnFSa2ZmZGhvTnU3TGtMOVgvMmVIUVI4eXNH?=
 =?utf-8?B?Q2F3MTRRY3FENnhUVU5aaFQzZmNuYjVYSVYwaVpkMi9IUDVST1JmNm91ZG8x?=
 =?utf-8?B?alIxSVpHeS9yVk5acU1PamxqM0libTYxbzlUeGN2bVdNNTBWRGgrUFNNNmx6?=
 =?utf-8?B?MFE5WllzTEJ3b08wdEErV1BYbHdaUFhyc00rZGRuZ0dTclI2QVVDU3poYXBk?=
 =?utf-8?B?akJZT0NUdXRDb2lUVDQwVEwvWG5OWEVWK2pkaWpZS3FyV1NBaVFpSVZnVGJJ?=
 =?utf-8?B?QUt1em5CUHNHUmNQbEFQejJ1eVpXMjlhaUY5ZC8zamhjR0YzNlNTbnFPd1dZ?=
 =?utf-8?B?N1EwL3Q2UURIRW02cm5ibWVkRmFISTNqa2pZajl5WXRVYldQVCsydE1lbnBG?=
 =?utf-8?B?K1c5TmxKRFBrTkIrUldwaFZwb2RBRHhHYkJ5TFdqRXE3ZW4wV1AvTm4zQlN1?=
 =?utf-8?B?OFNJTTg0WG9CYjdKKzNFYjdwY0NmR1ppa25BbDdPTlVkY2NMYTIwUmtXY2Rq?=
 =?utf-8?B?ZnRqQ2VySzVqZDVDM3drUmJ3Zmh3ZDZTa084eWNVVG9lWUVpbXY3QTRsakVh?=
 =?utf-8?B?cW50QmNydTllUEhUTmhJQzkybEk3aUFuaGdEZXJEdzhKaEtocVBDWkpiMEJ4?=
 =?utf-8?B?N2NMU0hLdDhUUXhnUnEzNmVtMFhjOFBWOEljQ0lOMmFRWTBwSHJET0JKSzdj?=
 =?utf-8?B?VkJmL25COFlwM0lRbGY3WDU4QjJlRUp4SUEzVVRiR09CTnd3M3ZDTUZCOWpC?=
 =?utf-8?B?T1ZlSUhkYmM1UTgvcDd6ZHJ1Lyt4NTcyZ01VN29mYkxnSVIydlhwd0hSUjY0?=
 =?utf-8?B?YW1TcWtQT1ZMazltbWE2RzZ4Ym9GOTlIQXlXaHZvdHQ0dlRzSGhtQ3k5YWVz?=
 =?utf-8?B?NVlYMktoWlJGR2ZYYWgrV3o1KytUSERnR1JZbTlYRFk4QldrUzl1Rk9ZUnRD?=
 =?utf-8?B?bkp1Q3RlZ1licnBEOFlTZXNqWmgwN2tjTkNRRHAwc3JDNk5xcWlOTmNjcWFN?=
 =?utf-8?B?SG5LVm5SRVRVclNHVE42cVpSS01kSFUwV3ZDU3ZQZ3BzTnZ3LzQyY0MyZ0My?=
 =?utf-8?B?TC9xS1E0ekl6VU1GRUw1Q2xiKzVBRkhXYktRbmFZOU1uNSs1TEo2TEVzellZ?=
 =?utf-8?B?a1NXN0dvSktOM3YxV0J1ejUrOFlxQ3VIMjQveEpkRjNrREUwc3JTZlVuUkxp?=
 =?utf-8?B?QXhjL3lMSEhKaVpKc0NBUUhnSTNwUkZtZFJDRW05SFlxOXFkSFNSNGFiK3lI?=
 =?utf-8?B?b2diM2ZNVlB2MWdpZ3BPbytpVzhVbFE4cVJKMnZiYjNhbjlndkhQeHErcVZ6?=
 =?utf-8?B?MkwzNEk5K1VWN2hpYWFWQkw2WlBYYnpIR01SOWU4OUcybkpQcjdqelA4Q3ZW?=
 =?utf-8?B?bldVSHEyWVJjbVNXOENyMXE2cXZCVmk0M0ZQYXEyb21WbkNjZy84RFZDTXhq?=
 =?utf-8?B?N0hrMmxCMVJwQ2FKTFhDMER5aG5qSzlpWXJQSVhHWVFZMWpTMVRJcVB2T1VG?=
 =?utf-8?B?bnRlemVtbzFGVzN6Q1RUU3BldTE4K2Y1SEdHZXh1NTErSUVJWkxLOXJ1Yy9L?=
 =?utf-8?B?M01qTXZNK2gwYWl6Q3lUVlE5dkhRTHBwUDVqTWhpZmlaL3JpODhldlowVTNZ?=
 =?utf-8?Q?l6BMi45SoCdh2Wm4HifXJ6T2K?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f6860b04-3831-4e9a-5031-08db87e95f26
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2023 23:47:39.7478
 (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: +U+JRRj82UmUaJfcwHFu+zS1l9x4MGsgziPEy04WDy2k2H2DcAU4CVIxOkeeDsJfo26VWel4mRb/caUWw8F9Pw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6250
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/19/23 06:48, Yosry Ahmed wrote:
> On Sun, Jul 16, 2023 at 6:58 PM Yin Fengwei <fengwei.yin@intel.com> wrote:
>>
>>
>>
>> On 7/17/23 08:35, Yu Zhao wrote:
>>> On Sun, Jul 16, 2023 at 6:00 PM Yin, Fengwei <fengwei.yin@intel.com> wrote:
>>>>
>>>> On 7/15/2023 2:06 PM, Yu Zhao wrote:
>>>>> There is a problem here that I didn't have the time to elaborate: we
>>>>> can't mlock() a folio that is within the range but not fully mapped
>>>>> because this folio can be on the deferred split queue. When the split
>>>>> happens, those unmapped folios (not mapped by this vma but are mapped
>>>>> into other vmas) will be stranded on the unevictable lru.
>>>>
>>>> This should be fine unless I missed something. During large folio split,
>>>> the unmap_folio() will be migrate(anon)/unmap(file) folio. Folio will be
>>>> munlocked in unmap_folio(). So the head/tail pages will be evictable always.
>>>
>>> It's close but not entirely accurate: munlock can fail on isolated folios.
>> Yes. The munlock just clear PG_mlocked bit but with PG_unevictable left.
>>
>> Could this also happen against normal 4K page? I mean when user try to munlock
>> a normal 4K page and this 4K page is isolated. So it become unevictable page?
> 
> Looks like it can be possible. If cpu 1 is in __munlock_folio() and
> cpu 2 is isolating the folio for any purpose:
> 
> cpu1                                        cpu2
>                                                 isolate folio
> folio_test_clear_lru() // 0
>                                                 putback folio // add
> to unevictable list
> folio_test_clear_mlocked()
Yes. Yu showed this sequence to me in another email. I thought the putback_lru()
could correct the none-mlocked but unevictable folio. But it doesn't because
of this race.

> 
> 
> The page would be stranded on the unevictable list in this case, no?
> Maybe we should only try to isolate the page (clear PG_lru) after we
> possibly clear PG_mlocked? In this case if we fail to isolate we know
> for sure that whoever has the page isolated will observe that
> PG_mlocked is clear and correctly make the page evictable.
> 
> This probably would be complicated with the current implementation, as
> we first need to decrement mlock_count to determine if we want to
> clear PG_mlocked, and to do so we need to isolate the page as
> mlock_count overlays page->lru. With the proposal in [1] to rework
> mlock_count, it might be much simpler as far as I can tell. I intend
> to refresh this proposal soon-ish.
> 
> [1]https://lore.kernel.org/lkml/20230618065719.1363271-1-yosryahmed@google.com/
> 
>>
>>
>> Regards
>> Yin, Fengwei
>>