Personally, I think the ecores should keep it.

Let the p cores run free, and Microsoft figure out the scheduler requirements to support it or disable it.

If required, have a bios option to set the boot core to p or e.

Problem solved.

But I'd also love it if this happened:
Intel wants to drop 16/32bit. A possible opportunity...?

myne wrote on 2024-10-01, 03:18:

Personally, I think the ecores should keep it.

Let the p cores run free, and Microsoft figure out the scheduler requirements to support it or disable it.

If required, have a bios option to set the boot core to p or e.

Highly unlikely to happen, Intel has decided on 64-bit UEFI only, no CSM. Legacy mode is essentially unused on modern systems, hence this proposal to remove it.

Intel doesn't use it, but AMI still support it, and unless somethings changed, most mfgs still add it.

myne wrote on 2024-10-01, 03:18:

Let the p cores run free, and Microsoft figure out the scheduler requirements to support it or disable it.

Consider that Intel decided to throw away AVX512 (which is much more of a crown jewel rather than x86 compatibility),
rather than end up in a "P-cores support it, E-cores don't, let MS figure out the scheduler requirements" situation. So no one has much faith in MS figuring out anything...

Intel terminates x86S initiative
https://www.tomshardware.com/pc-components/cp … comes-to-an-end

Albeit don't read too much onto it -- likely it will show up again soon.

I guess Intel realized that they couldn't beat ARM on pricing and energy efficiency, and that legacy software compatibility was actually the only advantage that they had left. 😅

It's not like eliminating legacy cruft would suddenly solve all their problems. Although it might make for some efficiency improvements, I don't think it's the main cause of what's been holding them back these last few years.

I mean, isn't the x86 ISA already kind an abstraction on top of their microcode layer?

As it happens, I just read this on LKML (Linux Kernel Mailing List) from a Microsoft engineer relating to a proposed a patch to the reboot codepath:

These are X86_64 systems that boot off of confguration in DeviceTree, and neither ACPI, BIOS, nor UEFI are present. The processors start running in the long mode right off the bat, and the physical memory below 4GiB is non-RAM or reserved. The systems are virtual machines.

It's only a VM but starting straight in long mode means X86S so they are clearly experimenting with the concept and using DeviceTree (a method of describing the hardware components) probably means the firmware isn't ready yet.

I too suspect this will come back, perhaps as a broader proposal by the consortium.

I wouldn't read too much into that - remember that the windows subsystem for linux is a thing...

Good point, it could just mean a faster booting WSL2 session.

There are plenty of examples of kernel configuration or drivers that do not exist in hardware, for things like virtual machines 😀 Starting in long mode actually not that far fetched, simply because, that really can just do that...

Now that I think about it, my guess is that x86S got put on hold due to the recent large workforce reductions.