Re: [PATCH 0/2] Make tunable a default feature

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 17/03/23 08:15, Siddhesh Poyarekar wrote:
> On 2023-03-15 16:05, Adhemerval Zanella Netto wrote:
>> On 14/03/23 15:02, Siddhesh Poyarekar wrote:
>>> On 2023-03-13 15:06, Adhemerval Zanella wrote:
>>>> It is enabled as default since 2.26, some features option require it
>>>> (such as hwcap mask, huge pages support, and lock elisition tuning),
>>>> and assuming its support also simplifies the build permutation.
>>>
>>> from a historical perspective, there was not just the question of enabling tunables but also providing multiple ways to read tunables, each having its own parser.  That is why there's a 'valstring' as an option for --enable-tunables.
>>
>> Does it really make sense to provide such option, where multiple distributions
>> would support different tunables? I don't this much as way forward, it would require
>> additional effort to document, along with some prudence to make it concise. And
>> its has the inherent problem of fragmentation.
> 
> Yeah I agree it doesn't make a lot of sense anymore; I think we made it like that to bake in some flexibility for use cases we weren't aware of yet.  I mentioned it here in the hope that folks who were part of the conversation then and have better memory than I would be able to pitch in with additional context :)
> 
>>> Over the years there haven't really been any other ideas to read tunables.  There's the idea of systemwide tunables through, e.g. ld.so.conf that we'd like to have at some point, but that is more effective alongside valstring than as an either-or feature.
>>
>> For ld.so cache, the program can use DF_1_NODEFLIB to either avoid its costs or
>> not use system cache (if its uses RUNPATH).  I think a system-wide tunable would
>> require a similar scheme, where the program can opt-out if required.
> 
> Actually I was thinking of systemwide tunables as the canonical way to apply default rules that *won't* get overridden by users.  That could allow users to, e.g. lock down memory tagging on a systemwide basis if needed, or put a hard upper or lower limit on some of the malloc tunables.  The scheme would work similar to rlimit, but it shouldn't be misunderstood to be a security feature in that sense; applications can always work around a malloc tunable limit by rolling their own allocator.

I think it might make sense for tunables that change the program semantic, such
as security hardening; although I don't think it really fits for performance
oriented ones (such malloc or pthread tuning).  So maybe we can define a global
file format where the administrator can set where setuid binaries can use it,
and if uses can overwrite it.  My initial idea would be something quite simple,
similar to sysctl.conf:

$ cat /etc/glibc-tunables.conf
# tunable                       setuid   override
glibc.cpu.hwcaps=-AVX512F,-AVX2      1          0
glibc.malloc.trim_threshold=128      1          1
glibc.malloc.tcache_count=2          0          1

And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out
any performance or behavior difference any tunable might incur.  Although with
your idea of enforceable tunable, I think it does not make much sense.

> 
>>> There's also conceivably a use case for having only systemwide tunables without any valstring override but maybe that should get supported when it's actually needed by someone.  So in summary, I'm not aware of anybody using --disable-tunables, so I'm not opposed to removing the configure flag altogether and simplifying the code.  Hopefully if someone is using it they'll come forward before this patchset gets accepted.
>>
>> Alright, so I think it should be good to setup this for next release then.
> 
> Yep.  I don't know how we can make this more widely visible before we drop the option.  Maybe @gnutools could tweet about it.  If there are no major objections in the next week or so I'll do a proper review of the patchset.
> 
> Thanks,
> Sid