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 ADE35C71136 for ; Thu, 12 Jun 2025 11:37:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 505626B0089; Thu, 12 Jun 2025 07:37:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DDF56B008A; Thu, 12 Jun 2025 07:37:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4195B6B008C; Thu, 12 Jun 2025 07:37:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 220506B0089 for ; Thu, 12 Jun 2025 07:37:34 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BF11C1D7508 for ; Thu, 12 Jun 2025 11:37:33 +0000 (UTC) X-FDA: 83546548386.16.435C774 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by imf20.hostedemail.com (Postfix) with ESMTP id D6C411C0006 for ; Thu, 12 Jun 2025 11:37:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=xjQ3RZjV; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf20.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.132 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=1749728252; 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=QSVPGRlqsJRFkbLxkOY6dxpAL7NHJT8NvpFrxAWvBSo=; b=18ieE82VaCGSpWpuqvuRQqioNJMAJe5nXb+sWOEQdmHj5wEVNFMB7hY5p6zqZVdMLrdOxW 4qmq54PZq24CDudz7Vgft24sKPtM94CpS5K7LIZosrRtDkNzjxPDOP1LjI8aAt4ColGAuD achsVdW981T6WIh6YH7F2CBu2Zyi5nM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749728252; a=rsa-sha256; cv=none; b=6U3fZ/MQ68g2TNwe2NZ+VEzkRjCBoXmZCmp/OOhRjnakznu694/jVHNzdeDjwJnxO69tyN FgiokVce2w5OseJ40y6hxV+myUKrgQsKx+nzyaZkx3S7AAc63ui1kUfjiUiy9TAGciSzG+ rrTPq0k08gWEWz4hWbyQFBr9LyDcLeg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=xjQ3RZjV; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf20.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1749728247; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=QSVPGRlqsJRFkbLxkOY6dxpAL7NHJT8NvpFrxAWvBSo=; b=xjQ3RZjVCCjkcpwexdxrwV6+d9PK9YQ35JQafCagVOespd90VW7xpiR27yi4d2sEvmQg2TB2/pNQJaT7Na3qTS10C38cxs+LIW/YC1ylZJ9NbaA11JEHuKD5WBCiDV4AqOypYykEa0SM85Uy2ypzV/OTx3oDJ1ZAlskRIgUj93M= Received: from 30.121.46.129(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WdgxZ0V_1749728243 cluster:ay36) by smtp.aliyun-inc.com; Thu, 12 Jun 2025 19:37:24 +0800 Message-ID: <42b76dbc-d1a1-4d00-b139-c50e0abf8b0c@linux.alibaba.com> Date: Thu, 12 Jun 2025 19:37:23 +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: From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D6C411C0006 X-Stat-Signature: wg9ie5ss8naj9jphjgm8owyiamy1ndde X-Rspam-User: X-HE-Tag: 1749728250-588330 X-HE-Meta: U2FsdGVkX1+CK2nCGARM2zYon8VvhHM9maYqJxPCZG6y2MJfnqUlntI/TVDF8tAu5HsB/v2BHvw2DHYKDBZmn9gF8ZmdlVmFEBiP9rfm9WTN1Y9YXVRgCSCmfqa8G2tC9rrbVmlgfCOe/MZHtOAajE4YfIZXNQDWyG0YHIJgul9n1b6Ykub0nBpcjy4UJ0lpzQkqCg2O04AVFPFkKqxVKUJgdL5lQB4ZCVl6mxrjRlE6C72Rk5VhgENAD9HphfZhB8o9NU6gq9btghOIBOIpQweLWJlZaw1SPKKHfat+HFSwC8TH5a5ztr7C9Iw/6UwUqqBbbhasb5SmRKhTkHTtOMRTiYftQDMhRc/Qs+Gbd3wNPQhaHiTkNcSoP2lZ3iLC4mn1hOCtceIDOpMnwFKx89vl1uTrsPcie2GcZe75J76XEhe9iYJqFCAAz7jZxDjVvhd74j9dmYhKEiemAY3XOUu1n4GT3b6p+GOq2zuxnYe7zNCIpLcTtHwKyMT/W4lv2vKJ9jxyIwa22cWB+PhfeMI9PtffZXCOkTMO5Ouuz7LGThir3V8b6hE9ta91Dc8vp4HTN+QWKIXH02/4jayrlR7gI0Ook3KB704onIcw4smzH/PzQC2HTp8pkyf53E6ib5r22Y5aZgzrrAA546oQDtTz+flCXeEzPZ834ntDTvGNReTwIwzHqVzF0N1q+idrcZocLjpHA2ikgJ425qcv3nokDqZWiFPDl+wiIVn57apjN9mqHKEvCf2TVfQkB8Hb+hLhrzH1oIYbe6XRKZYnJFPy5I7eDysq9URXC1Hxm3noxzIDzy6dh0+SThFXUw83ez22o7acIyoPvPCurE1rZqVMf4sKtCrb/PGJUyLawxYzvUAycdljzy4iQGUeA6bImksHGoqxXmsgIInnJSE3E9Fqpv4d0FJzG1HqghzDZkoPUDWQpLAHlCIP7qkH7RnkYUYZdBbGy8ha1OrgnHB AIklY1lv U3WCl1JbCi1SOtNpdxQJPMuV2W83oT0392CuZpcSeyZcuJOAFJXxr7pWmA+BsIklmEeG8sJ0nmdqqs+DBnWmfGo8iYszDizsWe87YnbNPMzfsuxaeNtPkNHcvf/5gQCndhsuL/g3d9pb/Rk2S5+A+01aHNchEHhGbFLYIgfH9UN1944jW7HjgX+UpGliLaT2BTKrivhki4xdd+DF5wG7Acl1eQNzNqYaoMQAyIwuhvzoIjvol5nfSI2vkxCNM+FN5M+t6aFd/1f11EejgmiZ70dYINVe2PmbDTZ1v9Jfl7SU5qgScVgv4R5jSR6a3yJkebhSxp81A6xnzHNbt5WQqQdFn+Q== 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 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. >> 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. I know this kind of case is very rare and may not even be detectable in tests. At least, I couldn't reproduce it. But I prefer to keep the original test logic and fix the issue without making further changes.