[patch v4 0/4] System-wide tunables

[Yury Khrustalev]

Just catching up...

On Mon, Feb 09, 2026 at 09:04:43PM +0000, Sam James wrote:
> DJ Delorie <dj@redhat.com> writes:
> 
> > Yury Khrustalev <yury.khrustalev@arm.com> writes:
> >> I think we should come back to this patch as this functionality
> >> will be of great help. Let's make it done by 2.44.
> 
> +1.
> 
> >>
> >> DJ, how can I help?
> >
> > I'm working on a v5 based on Florian's feedback, so watch for that.
> 
> Please CC me on that as I'm happy to do my bit along with Yury. We'd
> really love to see this in.

Will do, thanks.

> 
> >
> > As for helping, I see two opportunities:
> >
> > 1. Technical review.  When you see v5, go through it and look for bugs,
> >    missing required functionality, etc.  "Could it work" checks.  I'm
> >    not asking for feature creep, just making sure the first version
> >    isn't buggy.
> >
> > 2. There are still a few design choices that aren't 100% consensus'd,
> >    which could use some discussion and someone to drive consensus,
> >    including:
> >
> >    - should the new settings be in ld.so.conf or their own file

IMO, having separate file is better because tunables are orthogonal to
other ld settings.

> >    - should the cache be reloadable over the life of a running program

Depends on when each tunable is used (has effect). We should probably
document for each of the tunables at what point in the process lifecycle
they are used. Some (e.g. those that affect ifuncs) are only used at the
start, so changing them during runtime would not make much sense. So,
maybe it's easier to only use changes for new processes. I suspect most
if not all of the tunables are used at startup, and even if the value is
cached internally in some global variable, changing it will probably be
untested.

> >    - how much pre-processing, pre-warning, etc should ldconfig do

Probably do robust error reporting with LD_DEBUG=tunables and otherwise
do one of the 2 things: fall-back to default or abort (depending on the
property of each tunable).

> > For the first, I argued for a separate file to keep from interfering
> > with sysadmins or scripts managing ld.so.conf, but process it with
> > ldconfig so that sysadmins or scripts that don't know about tunables
> > will at least do the right thing.  The counter argument is that having a
> > second set of file parsing code is more complexity and a source of bugs,
> > but the code is relatively short and copied from existing code.

Why can't we re-use the existing code to avoid duplication?

> > ...

I'll reply to v5 as well when I have time to test it.

Thanks,
Yury