This is the mail archive of the libc-alpha@sourceware.org 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 02/10] Add the low level infrastructure for pthreads lockelision with TSX


On 01/13/2013 02:41 PM, Andi Kleen wrote:
>> We need a framework and policy for tunables.
>>
>> I'll try to work something up and send it out to the list for discussion.
> 
> AFAIK there are two choices: environment variable(s) or config file.
> 
> config file is nicer, but harder to use (it's very convenient to set per
> app for testing). However what would work is also having an environment
> variable to override the config file.
> 
> config file would require one more syscall per program startup to check
> if the file is there (or 3+ if it's actually there), so it's slower.

For tunables I want to avoid configuration files at all costs.

The process *should* start with everything it needs to start running.

I'm going to be suggesting we should expose a generic API and 
environment variables.

>> Again, this is totally not your fault Andi, you've just touched a sore
>> spot where the *community* needs to do some work.
> 
> We already have a lot of scripts that use my existing format, so if 
> there's not a strong reason I would prefer to keep at least the basic
> format.  This is mainly for the basics (enabling/disabling), not the individual
> tunables. It's also useful to have a simple way to specify at least
> enabling/disabling.

Sure, but the fact that you have a lot of scripts shouldn't play into
the design of what is right for our users :-)

Honestly I think PTHREAD_MUTEX_ELISION=on/off is a better environment
variable since it explains almost intuitively what it does, but I'll
follow up on that separately.

Cheers,
Carlos.


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