From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC675C71136 for ; Thu, 12 Jun 2025 12:14:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E8F36B008C; Thu, 12 Jun 2025 08:14:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 599E36B0092; Thu, 12 Jun 2025 08:14:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 489156B0093; Thu, 12 Jun 2025 08:14:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 27B216B008C for ; Thu, 12 Jun 2025 08:14:46 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DF97E14136C for ; Thu, 12 Jun 2025 12:14:45 +0000 (UTC) X-FDA: 83546642130.15.9AFA1AE Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf24.hostedemail.com (Postfix) with ESMTP id 65251180003 for ; Thu, 12 Jun 2025 12:14:41 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=tkgfO8IG; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf24.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749730484; a=rsa-sha256; cv=none; b=vt3AS6hFYqnRSabxuBRJtNcnTQOBqvEnKYDQMWbaANXhBsxPw84V4uF9y8hXwZuX6LkALq F9xG5DECilLQD8okQDeY+9MoyRhCfxYc10RIxu0Vge/Ycd1SitaybD7WaX1sTIWEIz4lv/ cjoAgHsCdSHovlK6M28ogvCcuIS4rxY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=tkgfO8IG; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf24.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749730484; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sbCEUNMaN9u599ZS8ghGRn/n3p008D7oXfWjfSzogfk=; b=lCSlq4fRnmGRDEhrBJl5qZ+6rRStxP9AUrk8Lf05opd+ZT1B4njLk0nP3MU6QGR9ZceUSV Y/Ch2kfMzSgSc4YAOvtyeBDvRpNos976D6g+e9xqO+qceKXW52IJRdIacw8T6am4Y5whmK +owgwRUsc122h2vPHW0kg8y6XJA3YvU= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1749730475; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=sbCEUNMaN9u599ZS8ghGRn/n3p008D7oXfWjfSzogfk=; b=tkgfO8IG/TAuqInaYbq8amvGO06kpaiQ8LM10uJ5EtBC6AAR1V7vhTeg9a52oamjN0g9NAni7lfYiloZ05iyUbNR/zgwWk2oSS7s31HM66BoAYPwL8QbknToYtnD2lRPx8pFCRA70V9RYu210H6C9t+pi4q+u/v2SoFYee0YqNQ= Received: from 192.168.0.106(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WdgyX62_1749730473 cluster:ay36) by smtp.aliyun-inc.com; Thu, 12 Jun 2025 20:14:34 +0800 Message-ID: <8c6dcf96-adbf-4c25-b1ab-b172bdc91800@linux.alibaba.com> Date: Thu, 12 Jun 2025 20:14:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] selftests: khugepaged: fix the shmem collapse failure To: David Hildenbrand , akpm@linux-foundation.org Cc: lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, shuah@kernel.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org References: <42b76dbc-d1a1-4d00-b139-c50e0abf8b0c@linux.alibaba.com> <6ceb38ce-c16d-48f2-baca-fef79f8fc058@redhat.com> From: Baolin Wang In-Reply-To: <6ceb38ce-c16d-48f2-baca-fef79f8fc058@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam01 X-Stat-Signature: h1etpqp77ton5rk8b3kshwiegbc5jtmn X-Rspamd-Queue-Id: 65251180003 X-Rspam-User: X-HE-Tag: 1749730481-506043 X-HE-Meta: U2FsdGVkX1+T5LKBTo9CzB4pYqbWv8bgR4SxwCfPI/F5nEC+nlihMBsg2wtX9Zjpv3xpZ3X8hBtP9DcP3pM1mr4EN+F8kZes12x1BvHFXlVb6+vWykRCqU5LoYtmTR9bAq+dJirYjycD2J3NGP1bP7waN/YL9MWGVVkJw+6rwToUHXnuHYYu++sek9K/C73SYOnbjxRplexgpOhOlCl5w44RxD2UfcWY8LgSwBGOaLdpbwxlwTcgto6XpLl1UeakzOxyVkzcDIoi2OvwxTQnDrsg3H/wN5T22rybSnUUirXTA0ATsFNkbmBSvWANUwPKGDduo6Jak2U2kjAaNuJ3yITs1JGaz4+jzGPJmAkDTgZu610LlrSe9YKcqxOnzR+05pH8uAHDO+KeYM879nW8dOfQgkV8TpN+lrzuej4jfXbosnXkw3aMuBVGtcvYSXxubjD//6tmsKxXsLX5wu9WA6HHG31s+Jv0uxQQaVmwyauU6zY5he/g7BS+JqHCC0Ketkj9AjB5XwQqQKkxmio4LnQJ6fVuEEkaTpciy5tLGxbtsXtxSwx9Urs/6f1UqWTeyHFrRW7vm1PI9NHxaUP2EBnHTgzXSwXx+5E3RBBraWcTpiXMOAUTV3WalFUyI1OSRsvkNFJGC3snLlBRf2YL4VRpfPbQCKxBbNAxdvUEY7HybrHaRY0Kq3CuJKbRiKjLo5I7EVixQnw1TbRRlRg9VfKhh3xjnI007lcv+gyKD0Xdd/LPYMxbJXHYtULTZUAOebqpyvqJipuWfu4Diq/NMjU+w4a0MpaaSe436H2ua7w3TyQMxyttJwHvsJ+yo5ZOeWcz8oWt+wAtGiMh/wam0LPuN43gpUbH4gpl8yRh5nMe4++N3d/AxIdXsW5hN1NZE7OUTBWMdnKkE/FPqjlpDExlF1I2/6EAFF0ZMiyWFa1uGqslcarH3YrxR3ZP+Goyg/iMmFOtWHoZrNRnY4r LWvym4Fy TbSWgYapJcUPxHm/PK63MCapSHYi4NVN11Sg+fuOk1Dl1Zsmt224HVGxdp4tvf9QlN5DgCIoS+N2YmVlyNH20rVcm1ylrnU6JzfFqNOZ+uGG3wicHQKf56HXjqTrXySyPhSuNqJKrFrtrrQLyRLxvj2IAzP9HsuYZH5d7Rfanr78kApdVrKe3Yj7HdCN8vXlBix8m+N7nYrhy7Uc814zdSpsyuptFRmm34bqgSkucGt5K20t26aypgFKwrCLT6eZwkNXTz8VUKYND+UpZB4X5YvA5iF6onZ4T6pgqTINIDUQT9se4A9APO260Tm92tKjHftJG+PzwcFJW/rE+bNoXJnkO4A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2025/6/12 19:45, David Hildenbrand wrote: > On 12.06.25 13:37, Baolin Wang wrote: >> >> >> On 2025/6/12 18:08, David Hildenbrand wrote: >>> On 12.06.25 05:54, Baolin Wang wrote: >>>> When running the khugepaged selftest for shmem (./khugepaged >>>> all:shmem), >>> >>> Hmm, this combination is not run automatically through run_tests.sh, >>> right? IIUC, it only runs "./khugepaged" which tests anon only ... >>> >>> Should we add it there? Then I would probably have noticed that myself >>> earlier :) >> >> Yes, see patch 2. > > Yes, was pleasantly surprised when I found that :) > >> >>>> I encountered the following test failures: >>>> " >>>> Run test: collapse_full (khugepaged:shmem) >>>> Collapse multiple fully populated PTE table.... Fail >>>> ... >>>> Run test: collapse_single_pte_entry (khugepaged:shmem) >>>> Collapse PTE table with single PTE entry present.... Fail >>>> ... >>>> Run test: collapse_full_of_compound (khugepaged:shmem) >>>> Allocate huge page... OK >>>> Split huge page leaving single PTE page table full of compound >>>> pages... OK >>>> Collapse PTE table full of compound pages.... Fail >>>> " >>>> >>>> The reason for the failure is that, it will set MADV_NOHUGEPAGE to >>>> prevent >>>> khugepaged from continuing to scan shmem VMA after khugepaged finishes >>>> scanning in the wait_for_scan() function. Moreover, shmem requires a >>>> refault >>>> to establish PMD mappings. >>>> >>>> However, after commit 2b0f922323cc, PMD mappings are prevented if the >>>> VMA is >>>> set with MADV_NOHUGEPAGE flag, so shmem cannot establish PMD mappings >>>> during >>>> refault. >>> >>> Right. It's always problematic when we have some contradicting >>> information in the VMA vs. pagecache. >>> >>>> >>>> To fix this issue, we can set the MADV_NOHUGEPAGE flag after the shmem >>>> refault. >>>> With this fix, the shmem test case passes. >>>> >>>> Fixes: 2b0f922323cc ("mm: don't install PMD mappings when THPs are >>>> disabled by the hw/process/vma") >>>> Signed-off-by: Baolin Wang >>>> --- >>>>    tools/testing/selftests/mm/khugepaged.c | 3 +-- >>>>    1 file changed, 1 insertion(+), 2 deletions(-) >>>> >>>> diff --git a/tools/testing/selftests/mm/khugepaged.c >>>> b/tools/testing/selftests/mm/khugepaged.c >>>> index 8a4d34cce36b..d462f62d8116 100644 >>>> --- a/tools/testing/selftests/mm/khugepaged.c >>>> +++ b/tools/testing/selftests/mm/khugepaged.c >>>> @@ -561,8 +561,6 @@ static bool wait_for_scan(const char *msg, char >>>> *p, int nr_hpages, >>>>            usleep(TICK); >>>>        } >>>> -    madvise(p, nr_hpages * hpage_pmd_size, MADV_NOHUGEPAGE); >>>> - >>>>        return timeout == -1; >>>>    } >>>> @@ -585,6 +583,7 @@ static void khugepaged_collapse(const char *msg, >>>> char *p, int nr_hpages, >>>>        if (ops != &__anon_ops) >>>>            ops->fault(p, 0, nr_hpages * hpage_pmd_size); >>>> +    madvise(p, nr_hpages * hpage_pmd_size, MADV_NOHUGEPAGE); >>>>        if (ops->check_huge(p, expect ? nr_hpages : 0)) >>>>            success("OK"); >>>>        else >>> >>> It's a shame we have this weird interface: there is no way we can clear >>> VM_HUGEPAGE without setting VM_NOHUGEPAGE :( >> >> Right. >> >>> But, do we even care about setting MADV_NOHUGEPAGE at all? IIUC, we'll >>> almost immediately later call cleanup_area() where we munmap(), right? >> >> I tested removing the MADV_NOHUGEPAGE setting, and the khugepaged test >> cases all passed. >> >> However, a potential impact of removing MADV_NOHUGEPAGE is that, >> khugepaged might report 'timeout', but check_huge() would still report >> 'success' (assuming khugepaged tries to scan the VMA and successfully >> collapses it after the timeout). Such test result could be confusing. > > If we run into the timeout, we return "true" from wait_for_scan(), and > in khugepaged_collapse() returns immediately. > > So we wouldn't issue another check_huge() call in khugepaged_collapse(). > > Did I miss something? Ah, right. Sorry for the wrong example. Now I'm fine to drop the MADV_NOHUGEPAGE settiing. Thanks.