Doug S (foo.delete@this.bar.bar) on May 22, 2022 8:52 pm wrote:
> ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on May 22, 2022 11:51 am wrote:
> > You are overly protective of what the Linux kernel currently is. There is no vision of a future
> > of heterogeneous CPUs in your posts .... if heterogeneous desktop/notebook CPUs are inevitable
> > then you should have a plan for it or make a plan for it. (An example reason why heterogeneous
> > CPUs are inevitable in those markets is that endowing _all_ cores in a future desktop machine
> > with the ability to predict 4 branches per cycle would be problematic.)
>
>
> That already exists, Linux handles stuff like "big cores" that are wider and "small cores" that are
> narrower just fine, so long as they both execute the same ISA. What Linus doesn't want to see are
> cores that don't support the same ISA, with certain instructions only present on some cores.
>
> If the hardware people give us that Linux will support it, but that doesn't mean he shouldn't
> go around telling people why he thinks that would be a bad idea. You can't really "plan"
> for something like this until it appears and you know what you're working with.

I strongly disagree that it is impossible to plan for hetero-ISA multicore CPUs. The kernel is [mostly] in control of the CPU, not the other way round (not CPU in control of the kernel). Thus, approximately 90% of the complexity related to enabling efficient use of such CPUs is a software design problem, not a hardware design problem. In other words, it is about software design (aka: plan), and hardware is "just" providing execution resources for use by the kernel&apps.

If the Linux kernel was designed/prepared to take hetero-ISA CPUs seriously, then it would already be providing a clean and efficient interface between the kernel-space and the applications running in user-space related to communicating/negotiating information necessary to run applications on hetero-ISA CPUs efficiently. ---- By "communicating/negotiating information" I mean both directions (not just one direction): kernel -> userspace and userspace -> kernel.

In my opinion, it is a mistake to believe that hetero-ISA CPUs can be utilized efficiently without a bidirectional communication channel between the OS and the applications. But unfortunately, this is exactly the belief/viewpoint that Linus is advocating in relation to the Linux kernel.

Another OS component related to hetero-ISA CPUs in Linux is the ELF executable file format, which is, again, a software design problem, not a hardware design problem. It would be possible for ELF to be extended in ways that would make binary translation (=BT) much more efficient if the Linux kernel supported BT natively, for example by extending/virtualizing the x86 CALL instruction to support dispatch based on the CPU _core_ on which the CALL instruction is currently running (example: CALL strlen; and there exists an ELF section specifying which version of 'strlen' to actually call based on the CPU core's capabilities). ---- Then again, Linus's thoughts about what should Linux do to enable efficient use of hetero-ISA CPUs are mostly beside the point and it appears that he still believes that the enablement can be implemented by some "magical single-line patch" somewhere in the Linux kernel or without involving the kernel at all.

There exist multiple options of how to approach/solve this problem. I don't know which option will prevail over time, but I do know that as long as software developers believe that there exist zero options then it is unsolvable.

Just a sidenote: There is no AVX-256F (= AVX-2 + K_registers) on Alder Lake's E-cores. If there was then binary emulation of AVX-512F on E-cores would be much easier to implement. I believe that absence of AVX-256F has already been mentioned in some form somewhere on RWT forums.

-atom