Kernel Bisecting Has Never Been Faster Than With AMD EPYC + AMD Threadripper

[rawr]

It's not a blame thing. I didn't know who even submitted or wrote the patch. I'm saying that in light of Linus's observation plus Michael's testing, it's unexpected to me that the patch improves anything. Not trying to rock the boat or anything. I like Linus and everyone who contributes to the Kernel. I generally assume they're doing their best with good intentions.

The patch was not about performance improvement but about simplification and maintainability from what I have read.

So I assume that some corner case was overlooked performance-wise.

[milkylainen]

It's not a blame thing. I didn't know who even submitted or wrote the patch. I'm saying that in light of Linus's observation plus Michael's testing, it's unexpected to me that the patch improves anything. Not trying to rock the boat or anything. I like Linus and everyone who contributes to the Kernel. I generally assume they're doing their best with good intentions.

Absolutely not a blame thing. The Linux kernel is an amazing piece of software. It's just that there is no official feedback that you got performance right. It's is an aspect of the code that generally is not that extensively tested (in regression form) with the Linux kernel. You extensively test semantics and adherence to standards. You test intended functionality. You also give everyone a possibility to review the code. Which is amazing. Since the kernel development has a long history of incremental organic development it wouldn't be that difficult to add a official performance regression suite to the kernel development process. You could ignore the information coming from there, but it could be very valuable to rather immediately detect performance regressions before they are covered in years of work.