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
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
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
* 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
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..
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.
@@ -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