> It makes more sense when you read Torvalds' initial argument. I did but: > AVX-512 draws so much power that (especially in laptops) they have to lower the

> It makes more sense when you read Torvalds' initial argument. I did but: > AVX-512 draws so much power that (especially in laptops) they have to lower the base clock of the entire CPU. This doesn't matter too much if you're doing HPC, because lowering the clock 20% but gaining 200% in throughput is still a net win. Is still basically true for encoding tasks and other SIMD-heavy operations. > But the computer can't change the clock speed instantly, so there's a fairly large penalty for just executing some AVX-512 instructions and then immediately trying to go back to other tasks (which is what happens if you try to use AVX-512 to implement memcpy). This is interesting on this point: https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html There is a cost to switching frequencies but the cost is generally lower than the performance impact of the new frequency itself. Which kind of makes sense given how frequently dynamic frequency scaling and turbo boost/turbo core like to change the frequency of the CPU. That said, just because somebody's decided to try and use a CPU feature sub-optimally (e.g. by implementing memcpy with AVX-512 so that it gets used sporadically in the context of otherwise non-AVX related work), I don't think that necessarily justifies removing it. It does sound like the power management for it ought to be fixed, though. Is it just me or is the idea of having power management for a specific instruction extension rather than integrating it into the rest of the dynamic frequency scaling/turbo boost TDP management kind of a smell? But I do kind of buy into the idea in the sibling comment that the transistors might have been better spent on the iGPU, though - at least in the short term.