But notice the link in the other thread, to some benchmarks provided by the authors: https://lore.kernel.org/lkml/20201117232003.3580179-1-joel@joelfernandes.or

But notice the link in the other thread, to some benchmarks provided by the authors: https://lore.kernel.org/lkml/20201117232003.3580179-1-joel@joelfernandes.org/ https://lore.kernel.org/lkml/20201117232003.3580179-1-joel@j... With the "kernel protection" aspect enabled, the performance is the same as just disabling SMT. And this is their hand-picked benchmark. Changes like this were first proposed a hear and half ago I think, or longer, and rejected because the performance cost of making the scheduler consider this constraint cost more performance than just disabling SMT, so it wasn't worth the implementation complexity cost. But it's true that companies and customers still _want_ it, they want to get all their cores/threads for performance, and they want all the security... they just want to know they got those things, even if they really didn't, because who can really notice...