This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Put CPU-related tunables into a unique namespace?
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