Re: [PATCH v2 1/2] Add framework for tunables

[Florian Weimer <fweimer at redhat dot com>]

On 01/16/2016 07:55 PM, Siddhesh Poyarekar wrote:
> The tunables framework allows us to uniformly manage and expose global
> variables inside glibc as switches to users.  tunables/README has
> instructions for glibc developers to add new tunables.
> 
> Tunables support can be enabled by passing the --enable-tunables
> configure flag to the configure script.  This patch only adds a
> framework and does not pose any limitations on how tunable values are
> read from the user.  It also adds environment variables used in malloc
> behaviour tweaking to the tunables framework as a PoC of the
> compatibility interface.

I think it is a mid-term goal to support re-tuning of running processes
(from the outside).  It seems difficult to get there from what you have
posted, mainly for two reasons:

Tunable arguments are strings.  It is difficult patch strings into
running processes because of memory management issues (when is it safe
to free the old version?), and you'd have to call the registered
callback to parse.

Tunables are registered programmatically.  This means that there is a
time where the tunables descriptor information is incomplete and only
partially initialized.  The introspecting process would have to
compensate for this rare corner case.


Furthermore, the tunables in glibc should be self-describing, but they
currently are not because there is no type information associated with
them, and it is not possible to determine the valid number ranges.

> +/* We avoid calling into the C library as much as we can, especially functions
> +   that we know could use tunables in future for some reason or the other.  For
> +   example, we call mmap directly instead of malloc because malloc uses
> +   tunables.  Similarly, the string functions may use tunables in future to
> +   select optimal routines and we want to make sure we stay out of the way and
> +   not invoke their initializers before the tunable list has been
> +   initialized.  */

This needs special compiler flags, otherwise it won't work as intended.
 The registered callbacks would have to be written in the same style
(atoi might not be safe there).

This problem will go away if you switch to a full declarative approach
(which does not need any initialization).

A declarative approach would also avoid a discussion whether we have to
mangle function pointers (because there wouldn't be any).

> +	  const char *name = envvars[i].env;
> +	  char *ename = alloca (len + 1);

Looks like an unbounded alloca, and it's in a loop even.

Florian