From: Usama Arif <usamaarif642@gmail.com>
To: David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Cc: linux-fsdevel@vger.kernel.org, corbet@lwn.net, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, hannes@cmpxchg.org,
baohua@kernel.org, shakeel.butt@linux.dev, riel@surriel.com,
ziy@nvidia.com, laoar.shao@gmail.com, dev.jain@arm.com,
baolin.wang@linux.alibaba.com, npache@redhat.com,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
ryan.roberts@arm.com, vbabka@suse.cz, jannh@google.com,
Arnd Bergmann <arnd@arndb.de>,
sj@kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH 4/5] selftests: prctl: introduce tests for disabling THPs completely
Date: Tue, 29 Jul 2025 23:13:50 +0100 [thread overview]
Message-ID: <4dc95e54-e0ef-4919-973a-748845897ef9@gmail.com> (raw)
In-Reply-To: <b9c72ab9-9687-4953-adfe-0a588a6dd0f7@redhat.com>
>> +
>> + self->pmdsize = read_pmd_pagesize();
>> + if (!self->pmdsize)
>> + SKIP(return, "Unable to read PMD size\n");
>> +
>> + thp_read_settings(&self->settings);
>> + self->settings.thp_enabled = THP_MADVISE;
>> + self->settings.hugepages[sz2ord(self->pmdsize, getpagesize())].enabled = THP_INHERIT;
>> + thp_save_settings();
>> + thp_push_settings(&self->settings);
>
> push without pop, should that be alarming? :)
>
> Can we just use thp_write_settings()? (not sure why that push/pop is required ... is it?)
>
Thanks for the reviews!
Ack on the previous comments, I have fixed them and will include in next revision.
Yes, I think we can replace thp_push_settings with thp_write_settings.
For this, I actually just copied what cow.c and uffd-wp-mremap.c are doing :)
You can see in these 2 files that we do [1]
- thp_read_settings / thp_save_settings
- thp_push_settings
Than we run the experiment
and at the end we do [2]
- thp_restore_settings
i.e. there is no pop.
I think we can change the thp_push_settings to thp_write_settings in [3] and [4] as well?
I can fix and test it if it makes sense. It should prevent people like me from making a
similar mistake when they just copy from it :)
[1] https://elixir.bootlin.com/linux/v6.16/source/tools/testing/selftests/mm/cow.c#L1884
[2] https://elixir.bootlin.com/linux/v6.16/source/tools/testing/selftests/mm/cow.c#L1911
[3] https://elixir.bootlin.com/linux/v6.16/source/tools/testing/selftests/mm/cow.c#L1886
[4] https://elixir.bootlin.com/linux/v6.16/source/tools/testing/selftests/mm/uffd-wp-mremap.c#L355
>> +}
>> +
>> +FIXTURE_TEARDOWN(prctl_thp_disable_completely)
>> +{> + thp_restore_settings();
>> +}
>> +
>> +/* prctl_thp_disable_except_madvise fixture sets system THP setting to madvise */
>> +static void prctl_thp_disable_completely(struct __test_metadata *const _metadata,
>> + size_t pmdsize)
>> +{
>> + int res = 0;
>> +
>> + res = prctl(PR_GET_THP_DISABLE, NULL, NULL, NULL, NULL);
>> + ASSERT_EQ(res, 1);
>> +
>> + /* global = madvise, process = never, we shouldn't get HPs even with madvise */
>
> s/HPs/THPs/
>
>> + res = test_mmap_thp(NONE, pmdsize);
>> + ASSERT_EQ(res, 0);
>> +
>> + res = test_mmap_thp(HUGE, pmdsize);
>> + ASSERT_EQ(res, 0);
>> +
>> + res = test_mmap_thp(COLLAPSE, pmdsize);
>> + ASSERT_EQ(res, 0);
>> +
>> + /* Reset to system policy */
>> + res = prctl(PR_SET_THP_DISABLE, 0, NULL, NULL, NULL);
>> + ASSERT_EQ(res, 0);
>> +
>> + /* global = madvise */
>> + res = test_mmap_thp(NONE, pmdsize);
>> + ASSERT_EQ(res, 0);
>> +
>> + res = test_mmap_thp(HUGE, pmdsize);
>> + ASSERT_EQ(res, 1);
>> +
>> + res = test_mmap_thp(COLLAPSE, pmdsize);
>> + ASSERT_EQ(res, 1);
>
>
> Makes me wonder: should we test for global=always and global=always?
Do you mean global=madvise and global=always?>
> (or simply for all possible values, including global=never if easily possible?)
>
> At least testing with global=always should exercise more possible paths
> than global=always (esp., test_mmap_thp(NONE, pmdsize) which would
> never apply in madvise mode).
>
lol I think over here as well you meant madvise in the 2nd instance.
I was just looking at other selftests and I saw FIXTURE_VARIANT_ADD, I think we can
use that to do it without replicating too much code. Let me see if I
can use that and do it for never, madvise and always. If it doesnt help
there might be some code replication, but that should be ok.
Thanks!
next prev parent reply other threads:[~2025-07-29 22:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 16:22 [PATCH 0/5] prctl: extend PR_SET_THP_DISABLE to only provide THPs when advised Usama Arif
2025-07-25 16:22 ` [PATCH 1/5] prctl: extend PR_SET_THP_DISABLE to optionally exclude VM_HUGEPAGE Usama Arif
2025-07-30 19:31 ` Lorenzo Stoakes
2025-07-30 19:42 ` Usama Arif
2025-07-31 8:29 ` Lorenzo Stoakes
2025-07-31 8:38 ` David Hildenbrand
2025-07-31 9:09 ` Lorenzo Stoakes
2025-07-31 10:32 ` Usama Arif
2025-07-25 16:22 ` [PATCH 2/5] mm/huge_memory: convert "tva_flags" to "enum tva_type" for thp_vma_allowable_order*() Usama Arif
2025-07-28 13:28 ` David Hildenbrand
2025-07-28 14:09 ` Usama Arif
2025-07-25 16:22 ` [PATCH 3/5] mm/huge_memory: treat MADV_COLLAPSE as an advise with PR_THP_DISABLE_EXCEPT_ADVISED Usama Arif
2025-07-25 16:22 ` [PATCH 4/5] selftests: prctl: introduce tests for disabling THPs completely Usama Arif
2025-07-28 15:06 ` David Hildenbrand
2025-07-29 22:13 ` Usama Arif [this message]
2025-07-30 11:39 ` David Hildenbrand
2025-07-25 16:22 ` [PATCH 5/5] selftests: prctl: introduce tests for disabling THPs except for madvise Usama Arif
2025-07-28 16:55 ` SeongJae Park
2025-07-29 22:17 ` Usama Arif
-- strict thread matches above, loose matches on Subject: below --
2025-07-31 12:18 [PATCH 0/5] prctl: extend PR_SET_THP_DISABLE to only provide THPs when advised Usama Arif
2025-07-31 12:18 ` [PATCH 4/5] selftests: prctl: introduce tests for disabling THPs completely Usama Arif
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4dc95e54-e0ef-4919-973a-748845897ef9@gmail.com \
--to=usamaarif642@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=laoar.shao@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).