Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Thu, 2015-09-10 at 13:40 -0400, Siddhesh Poyarekar wrote:
> ----- Original Message -----
> > Environment variables affect process trees, and can only be set at
> > process start time.  Is this really the behavior we want?  The advantage
> > is that it's not system-wide, but that's the disadvantage as well.
> 
> That is in fact the behaviour we want for now, a per-process method to tune
> program behaviour. Inheritance of the behaviour currently exists since the
> current tunables replace environment variables, so that won't be anything
> new.
> 
> > The presence of environment variables changes stack alignment and where
> > cache line boundaries fall on the stack.  For performance tunables, this
> > can be problematic because the effect from setting the environment
> > variable itself can easily outrank the impact of the actual tuning change:
> 
> I believe this will happen regardless of whether we use a singled envvar or
> multiple envvars because the space required for that data will be more or
> less the same.  For performance tunables, the recommended method for
> measurement in such a scenario would be to keep the tunable defined and
> change the value to determine which value is better, i.e. explicitly specify
> even the default value so that it produces a similar stack alignment.
> 
Actually the stack alignment could be easily fixed in _start when the
first frame it set. Each platform could insure the main stack starts on
a consistent cache line boundary. 


> > LD_* might benefit from some existing security filters.  Maybe that's
> > sufficient for staying within that namespace?
> 
> I don't understand, could you please rephrase?  LD_* already has some
> security filters in place, i.e. a lot of them are scrubbed away for setuid
> binaries.  Are you suggesting doing similar for GLIBC_* variables too?  I
> don't see why not.
> 
> Siddhesh
>