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


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