Re: Put CPU-related tunables into a unique namespace?

[Carlos O'Donell <carlos at redhat dot com>]

On 07/12/2018 12:23 PM, Siddhesh Poyarekar wrote:
> 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?

Sure! I like that.

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

I understood it like that. You have to argue for generic inclusion first,
and if not explain why not.

>> * 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) :)

Oh, that's a good suggestion.

Yes, it's entirely about UI and optics and how do our users know what
flags apply on what hardware.

I like your suggestion.

-- 
Cheers,
Carlos.