From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFA58223714; Thu, 12 Jun 2025 12:14:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749730481; cv=none; b=quewGoyH0MctZS00elvMWrcVUEa1upfKUcqPlkKIUTPATCuFsODdWVlQuXj0CWYF/kNPMtuC73ms+k41CSU/u4sgoCJfSPa8ECv83LhxMDnxrdD9/REvwwrmdoFMSYSJoOm/SY0fe2CQ+lWqAqiM8NAGGIPj+EJRrnNUsiZYo3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749730481; c=relaxed/simple; bh=5Ff3aJ0jv+xKGQeZHfIxfYOLj+J7heE56PKBBO8OEOA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jvo9biV+dAuPkPz/xyhwQ+yV63J1gacZVIemWDm0Djwvp9ygAsXTQViIxrZxUbOz7ahPQAE9Rif+NPheib2uXoqDNViV6+q2Ox3xcNfJ8warxMwfCfPImmZTYuZzqdJeAxj/0wqMK2zT1K4RoCl+7U/1x4nACnBaW0ky9YaKJk0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=HEFUCRj7; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="HEFUCRj7" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1749730474; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=sbCEUNMaN9u599ZS8ghGRn/n3p008D7oXfWjfSzogfk=; b=HEFUCRj7A77IfOLBMUicb/3lpV7VBCiU/c2nCCGeStXpkgjQyLj6gUIwOSOl7xpduoEKqqHIbADL7lNJhi7tF2ibiS2nXDejt2/pUytxnXf3IsRcnJcMpa24W2Im/GIVVCoFRZGxFh7Rm/pdgn+VVIk0oq8HwjdCfRGXGtFwUlE= 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 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.