[PATCH v2] support: Also run malloc hugetlb=1 tests when transparent hugepage is 'always'

[Adhemerval Zanella Netto]

On 03/06/26 09:55, Andreas Schwab wrote:
> On Jun 02 2026, Adhemerval Zanella wrote:
> 
>> diff --git a/support/support_check_hugetlb.c b/support/support_check_hugetlb.c
>> index be7e10e80d6..c73946c894c 100644
>> --- a/support/support_check_hugetlb.c
>> +++ b/support/support_check_hugetlb.c
>> @@ -28,13 +28,14 @@
>>  #include <support/check.h>
>>  
>>  bool
>> -support_thp_is_madvise (void)
>> +support_thp_work_madvise (void)
>>  {
>>    int fd = open ("/sys/kernel/mm/transparent_hugepage/enabled", O_RDONLY);
>>    if (fd == -1)
>>      return false;
>>  
>>  #define MODE_MADVISE "always [madvise] never\n"
>> +#define MODE_ALWAYS  "[always] madvise never\n"
>>  
>>    char str[sizeof(MODE_MADVISE)];
>>    ssize_t s = read (fd, str, sizeof (str));
>> @@ -42,7 +43,7 @@ support_thp_is_madvise (void)
>>    if (s != sizeof (str) - 1)
>>      return false;
>>    str[s] = '\0';
>> -  return strcmp (str, MODE_MADVISE) == 0;
>> +  return strcmp (str, MODE_MADVISE) == 0 || strcmp (str, MODE_ALWAYS) == 0;
> 
> What happens if transparent_hugepage grows another option?
> 

My understanding if the the top-level enabled value set (always/madvise/never) has 
been stable for a very long time, and it is documented in
Documentation/admin-guide/mm/transhuge.rst. So I would consider an stable ABI.

Change either its size or adding new fields will break not only glibc
(sysdeps/unix/sysv/linux/hugepages.c), but also jemalloc [1] and potentially
bolt [2] (it does use strstr, but it reads the value with a limited buffer).

The multi-size THP (mTHP) did extended it, but through per-size knobs — 
/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled (it advertise a
fourth value: inherit).

So I think it is highly unlikely kernel devs to change it.

[1] https://sources.debian.org/src/jemalloc/5.3.1-2/src/pages.c?hl=833#L833
[2] https://codebrowser.dev/llvm/bolt/runtime/hugify.cpp.html