This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Feb 10, 2016 at 02:39:37PM +0100, Florian Weimer wrote:
> 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:

In general getting to re-tuning running processes will require
significant changes anyway and I don't want to over-engineer the
current solution based on that target.  Of course, if you have an idea
that doesn't need too much additional infrastructure then I am very
interested in hearing that.

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

<see comment about self-description>

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

The introspecting process will have to synchronize with the target in
some other way.  That would be a necessary enhancement regardless of
the way the data is represented.

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

I had done an initial mockup with self-describing tunables but I don't
remember why I had dropped it.  Maybe I could try it again and see if
I come across the problem again.  That should also fix the string
patching issue.

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

It is bounded by the length of the tunable name, which is specified in
the glibc source.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]