Document glibc.pthread.stack_hugetlb does nothing in recent kernels

Message ID 20250120204233.12181-1-cristian@rodriguez.im (mailing list archive)
State New
Headers
Series Document glibc.pthread.stack_hugetlb does nothing in recent kernels |

Checks

Context Check Description
redhat-pt-bot/TryBot-apply_patch success Patch applied to master at the time it was sent
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_glibc_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_glibc_check--master-arm success Test passed

Commit Message

Cristian Rodríguez Jan. 20, 2025, 8:42 p.m. UTC
  Since
c4608d1bf7c: mm: mmap: map MAP_STACK to VM_NOHUGEPAGE

All MAP_STACK allocations imply NOHUGEPAGE and the tunable does nothing.

Signed-off-by: Cristian Rodríguez <cristian@rodriguez.im>
---
 manual/tunables.texi | 4 ++++
 1 file changed, 4 insertions(+)
  

Comments

Adhemerval Zanella Netto Jan. 21, 2025, 3:28 p.m. UTC | #1
On 20/01/25 17:42, Cristian Rodríguez wrote:
> Since
> c4608d1bf7c: mm: mmap: map MAP_STACK to VM_NOHUGEPAGE
> 
> All MAP_STACK allocations imply NOHUGEPAGE and the tunable does nothing.
> 
> Signed-off-by: Cristian Rodríguez <cristian@rodriguez.im>
> ---
>  manual/tunables.texi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/manual/tunables.texi b/manual/tunables.texi
> index 7f0246c789..468432fc57 100644
> --- a/manual/tunables.texi
> +++ b/manual/tunables.texi
> @@ -509,6 +509,10 @@ its value to @code{0} enables the use of @code{madvise} with
>  This is a memory utilization optimization, since internal glibc setup of either
>  the thread descriptor and the guard page might force the kernel to move the
>  thread stack originally backup by Huge Pages to default pages.
> +
> +This tunable has no effect on the linux kernel version 6.7

I think it was changed only for 6.8, and git describe seems to agree:

$ git describe c4608d1bf7c
v6.8-rc1-8-gc4608d1bf7c6

Besides that, the patch is ok.  Should we eventually phase out this tunable?

> +or later where MADV_NOHUGEPAGE is the default for stack mappings.
> +
>  @end deftp
>  
>  @node Hardware Capability Tunables
  
Florian Weimer Jan. 21, 2025, 7:21 p.m. UTC | #2
* Adhemerval Zanella Netto:

> On 20/01/25 17:42, Cristian Rodríguez wrote:
>> Since
>> c4608d1bf7c: mm: mmap: map MAP_STACK to VM_NOHUGEPAGE
>> 
>> All MAP_STACK allocations imply NOHUGEPAGE and the tunable does nothing.
>> 
>> Signed-off-by: Cristian Rodríguez <cristian@rodriguez.im>
>> ---
>>  manual/tunables.texi | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/manual/tunables.texi b/manual/tunables.texi
>> index 7f0246c789..468432fc57 100644
>> --- a/manual/tunables.texi
>> +++ b/manual/tunables.texi
>> @@ -509,6 +509,10 @@ its value to @code{0} enables the use of @code{madvise} with
>>  This is a memory utilization optimization, since internal glibc setup of either
>>  the thread descriptor and the guard page might force the kernel to move the
>>  thread stack originally backup by Huge Pages to default pages.
>> +
>> +This tunable has no effect on the linux kernel version 6.7

I think we generally write “Linux” (except where we allude to the
sysdeps/unix/sysv/linux directory).

> I think it was changed only for 6.8, and git describe seems to agree:
>
> $ git describe c4608d1bf7c
> v6.8-rc1-8-gc4608d1bf7c6
>
> Besides that, the patch is ok.  Should we eventually phase out this tunable?

It should be phased out, yes.

Thanks,
Florian
  
Cristian Rodríguez Jan. 21, 2025, 11:21 p.m. UTC | #3
On Tue, Jan 21, 2025 at 4:22 PM Florian Weimer <fweimer@redhat.com> wrote:

> It should be phased out, yes.

So, shall I post a patch removing this tunable ? add a deprecation
warning ( if there is such a way to inform the user it does not work?
I have not checked)
The docs also say this tunables are not ABI and that they might just go away..
  
Adhemerval Zanella Netto Jan. 22, 2025, 12:23 p.m. UTC | #4
On 21/01/25 20:21, Cristian Rodríguez wrote:
> On Tue, Jan 21, 2025 at 4:22 PM Florian Weimer <fweimer@redhat.com> wrote:
> 
>> It should be phased out, yes.
> 
> So, shall I post a patch removing this tunable ? add a deprecation
> warning ( if there is such a way to inform the user it does not work?
> I have not checked)
> The docs also say this tunables are not ABI and that they might just go away..

Yes, I think it would be better to just remove the tunable.  If I understand
correctly, the issue was introduced with efa7df3e3bb5 (Linux 6.7) and then
fixed by c4608d1bf7c (Linux 6.8), so we have only one Linux release where this
tunable might make sense.

As a side note, the tunable madvise also fails to handle error (where it does
not deallocate the thread stack); so one more point to just remove it.
  

Patch

diff --git a/manual/tunables.texi b/manual/tunables.texi
index 7f0246c789..468432fc57 100644
--- a/manual/tunables.texi
+++ b/manual/tunables.texi
@@ -509,6 +509,10 @@  its value to @code{0} enables the use of @code{madvise} with
 This is a memory utilization optimization, since internal glibc setup of either
 the thread descriptor and the guard page might force the kernel to move the
 thread stack originally backup by Huge Pages to default pages.
+
+This tunable has no effect on the linux kernel version 6.7
+or later where MADV_NOHUGEPAGE is the default for stack mappings.
+
 @end deftp
 
 @node Hardware Capability Tunables