[PATCH v6 4/4] Add system-wide tunables: Filters

[Yury Khrustalev]

On Mon, Mar 30, 2026 at 12:03:36PM -0400, DJ Delorie wrote:
> Yury Khrustalev <yury.khrustalev@arm.com> writes:
> > We should not take into account values of tunables. This would be a
> > mistake: like I said, some tunables don't have any monotonicity of
> > their values.
> 
> True, but some tunables *do* and why not let the admin have the option?

Let's do it step by step. What I propose will cover all possible
scenarios: admin enforces a value (1), recommends a value (2), doesn't
care (3).

> 
> Consider:
> 
> * Admin limits the number of malloc heaps to 16 because glibc
>   autodetects the number of CPUs wrong.

This will complicate things and we would have to assess how useful this
use case is going to be before we try to implement it.

Plus, we probably should avoid making tunables.conf Turing-complete,
otherwise it will become a vulnerability of its own :) If you allow to
narrow down the accepted range, you'd have to support both upper and
lower boundary. This is doable, but I'd rather add this in another
patch, but only if there is some need for this.

> 
> * User further limits it to 1 to avoid heap-related fragmentation.

Also, as far as setting tunables is concerned, there is no notion of
"limiting" anything: we set a value if we want to use a non-default one.

In a nutshell, let's keep it simple. We could try adding scripting
support, GPU acceleration, and distributed compute a few decayed protons
later :)