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

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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.

>> 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