Clang PGO Shot Down For Now From The Linux Kernel

[coder]

going the perf-route doesn't seem to be the obvious better option here in my eyes.

Here's a thought experiment. At present, what compiler you use to build the kernel is basically an internal detail. Once the thing is compiled, it works the same no matter what compiler you used (or so we expect). What the proposed mechanism does is expose a compiler-specific data format via an official kernel interface. Once that exists, there could start to be other uses people add for it, such as hot-path analysis tools. Also, compiler-specific details could start to leak out in other ways and places. Pretty soon, we could find a lot of momentum in the direction of tying the kernel to Clang, or at least disadvantaging any other compilers one might wish to use on it.

So, you could view this as the camel's nose under the tent. If Linus wants the kernel to be more compiler-agnostic, then I think there's wisdom in his position of limiting profiling information to the interface the kernel already has.

[CommunityMember]

Here's a thought experiment. At present, what compiler you use to build the kernel is basically an internal detail. Once the thing is compiled, it works the same no matter what compiler you used (or so we expect). What the proposed mechanism does is expose a compiler-specific data format via an official kernel interface. Once that exists, there could start to be other uses people add for it, such as hot-path analysis tools. Also, compiler-specific details could start to leak out in other ways and places. Pretty soon, we could find a lot of momentum in the direction of tying the kernel to Clang, or at least disadvantaging any other compilers one might wish to use on it.

Only if you believe that GCC is going to fail to keep up. And that would be admitting defeat now. And if you believe that, LLVM should be your preference anyway if you believe in meritocracy (let the best compiler "win").

So, do you believe GCC is going to fail to remain relevant?

So, you could view this as the camel's nose under the tent. If Linus wants the kernel to be more compiler-agnostic, then I think there's wisdom in his position of limiting profiling information to the interface the kernel already has.

And yet, for decades, the kernel was NOT compiler agnostic (it was GCC only), and almost no one cared, so this argument makes no sense unless you believe that GCC is going to fail to keep up and someone needs to help it stumble on (should GCC be a protected class as having "special needs"?).

Personally, I think that GCC can succeed, but only if people stop making excuses for what it is not, and propping it up based on philosophical arguments (which seem to boil down to "its not LLVM"), and make sure it remains successful by putting resources (i.e. money) into it. Resources does not insure success, of course, but they are necessary.

[ms178]

Here's a thought experiment. At present, what compiler you use to build the kernel is basically an internal detail. Once the thing is compiled, it works the same no matter what compiler you used (or so we expect). What the proposed mechanism does is expose a compiler-specific data format via an official kernel interface. Once that exists, there could start to be other uses people add for it, such as hot-path analysis tools. Also, compiler-specific details could start to leak out in other ways and places. Pretty soon, we could find a lot of momentum in the direction of tying the kernel to Clang, or at least disadvantaging any other compilers one might wish to use on it.

So, you could view this as the camel's nose under the tent. If Linus wants the kernel to be more compiler-agnostic, then I think there's wisdom in his position of limiting profiling information to the interface the kernel already has.

Well, the Kernel was tied to one compiler for a long time - there is a precedent here. And fair enough if Linus weights the argument brought up by you more than allowing progress on the LLVM/Clang side, but this comes with a downside (which I would weight higher than Linus did) and in my view his stance is neither consistent with past efforts nor would merging this work block any future work on the GCC side. Denying progress here with one compiler slows down progress overall as you are now limiting your possibilities to the slowest moving target. I still remember the asm-goto discussion where the Linux Kernel community demanded a lot from the LLVM/Clang folks to deliver and eventually they did, but the Linux community had no problem holding back compiler diversity in that case limiting themselves to GCC and its (more advanced) feature set for quite some time. Why aren't they consistent and allow the Clang side to progress with PGO while GCC lacks behind in that regard?! Heck, if they wanted to be consistent they should have blocked Clang's LTO support to be merged if they were that keen on using common infrastructure for both compilers, GCC's LTO Kernel support is still not in a mergable state and very different to Clang's, I've tried to fix a boot issue with Andi Kleen recently, but there is more work left on that front. Would you have wanted to hold back such a major performace oriented feature for longer than neccessary?

[coder]

Only if you believe that GCC is going to fail to keep up. And that would be admitting defeat now. And if you believe that, LLVM should be your preference anyway if you believe in meritocracy (let the best compiler "win").

So, do you believe GCC is going to fail to remain relevant?

I have two issues with the question:

1. It presumes GCC will quickly be enabled as a work-alike implementation.
2. The question implies a Clang vs. GCC duopoly.

And yet, for decades, the kernel was NOT compiler agnostic (it was GCC only),

But we like to make things better, right? The push for the kernel to support Clang should be taken not as a transition of which compiler the kernel is tied to, but instead a move to open it up to more compilers. Linux has been around for 30 years. We don't know if it'll be relevant in another 30, but the compiler landscape could change drastically in even 10 years' time. I can't say if he is, but Linus should be thinking in these terms.

I think it's a mistake to view this move as anti-LLVM. Instead, it should be seen as maintaining proper decoupling between the kernel and its compiler.

[coder]

Denying progress here with one compiler slows down progress overall as you are now limiting your possibilities to the slowest moving target.

No, I've not seen him require GCC to support similar functionality. He simply wanted the Clang patch to use the kernel's existing perf framework. I'd expect the same decision if the compiler in question were GCC, instead of Clang.

I still remember the asm-goto discussion where the Linux Kernel community demanded a lot from the LLVM/Clang folks ... Why aren't they consistent and allow the Clang side to progress with PGO while GCC lacks behind in that regard?!

I think it's not constructive to view it in partisan terms. You have to look at which principles they're upholding, in each case. I'm not saying there's no favoritism, but my read on this decision is that it's not the driving force.

[juarezr]

No, I've not seen him require GCC to support similar functionality. He simply wanted the Clang patch to use the kernel's existing perf framework. I'd expect the same decision if the compiler in question were GCC, instead of Clang.

I think it's not constructive to view it in partisan terms. You have to look at which principles they're upholding, in each case. I'm not saying there's no favoritism, but my read on this decision is that it's not the driving force.

Although I understand Linus's concern about using LLVM PGO/LTO in a kernel interface to userspace, perf doesn't look like a tool tailored for this finality.

It looks like riding your dog instead of riding your horse.

[smitty3268]

Would you have wanted to hold back such a major performace oriented feature for longer than neccessary?

How major is it, actually? Are there performance benchmarks on this?

Linus rejected pgo patches for gcc years ago too, so I don't think this is about the compiler at all. It's more that Linus doesn't view this as all that important that he needs it to get in right away, so he's being picky about things. That sort of thing goes on constantly in the kernel when it comes to tree-wide changes.

[xhustler]

Am with Linus on this one, use the existing perf framework. If it is lacking in anyway, fix it/beef it up. Also, am still not sold on the real world value of PGO for us 'dummies'. For Google and Facebook clusters may be, for my desktop, it seems like a lot of work for minuscule gain at best.

[mdedetrich]

Am with Linus on this one, use the existing perf framework. If it is lacking in anyway, fix it/beef it up. Also, am still not sold on the real world value of PGO for us 'dummies'. For Google and Facebook clusters may be, for my desktop, it seems like a lot of work for minuscule gain at best.

PGO is as good as the profiling information. If you have great profiling information than PGO can improve performance non trivially, both Chrome and Firefox use PGO for this reason.

I suspect an issue with something as generic as the Linux kernel is that people use it in very different ways, i.e. some people don't care about latency and do massively large workloads and you have vice versa.

[NobodyXu]

Torvalds is not "holding it off for a little while". He did not give a time line, he is not writing his own implementation, he is not doing anything, but to say no. Google's implementation works and Torvalds is only abusing his position to try and to get Google to write completely new code. Nothing about this is "perfectly reasonable". It is about as narcissistic as Trump's politics. Linux is governed by an autocracy and young people find nothing wrong with it.

I don’t get what’s wrong with requiring them to use existing perf infrastructure in the kernel.

It’s a fairly reasonable technical request for code reuse and he conveyed his reason clearly and it is reasonable.

I cannot get it why you are hating him.
He is just doing his job as a code reviewer, and what’s wrong with asking Google to do more jobs?
They are the one responsible for the PGO patch.