Put CPU-related tunables into a unique namespace?

[Siddhesh Poyarekar]

On 07/12/2018 09:01 PM, Carlos O'Donell wrote:
> OK, so a couple of questions for you?
> 
> * Should '.tune.' be removed considering these are *tunables*?

The 'tune' meant 'CPU tuning' for me when I had proposed it, so it isn't 
quite the same as 'tunable'.  Maybe call it 'perf' since they're all 
performance related?

Or maybe glibc.cpu.* and then rename glibc.tune.cpu to glibc.cpu.name?

> * You suggest we try to implement generic tunables first, discuss why
>    it should not be generic, and then only then put it in an arch-specific
>    tunables?

Yes.  To be clear, I'm not necessarily against arch-specific tunables. 
I see this process as a way to ensure that a thorough discussion is 
conducted before including a tunable.

> * Do you have a preferences for (a) or (b)?
>    https://www.sourceware.org/ml/libc-alpha/2018-07/msg00324.html

Technically you could have just architecture as a tunable namespace 
(i.e. glibc.x86.*) but I don't know if that's a useful logical 
categorization.

Having an architecture namespace inside a tunable namespace (or vice 
versa) seems like an unnecessary complication.  Is there any reason 
other than the way it looks, i.e. the ability to see that it is an 
x86-specific tunable?

If it's just that then I prefer the convention H J established with 
naming the tunables as "<arch>_" since it achieves the optics goal and 
doesn't add any complication to the parsing logic.

So in that sense, neither (a) nor (b) :)

Siddhesh