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.

It looks like x86S might not be dead after all.

Intel abandoned it shortly after they themselves initially proposed it. AMD hasn't shown any signs of embracing it, as far as I know.

However, a "mysterious new x86 CPU manufacturer", possibly RosaicLabs, has just committed to it, and has started to engage with the Linux kernel maintainers to lay the foundation for supporting their upcoming products.

Kind of crazy to have a completely new player in the x86 CPU market implementing the latest x86 architectural revisions even after Intel walked it back themselves. Let's see where this goes.

https://www.phoronix.com/news/x86-CPU-With-APX-x86S

I'd assume China.
Licensing will be a problem for everyone else.

I wonder if the US govt will lean on the Kernel team...

RosaicLabs is a US company. And if it turns out to be an other company, then perhaps it's Chinese, but don't bet on that entirely.

China is especially weary of US technologies these days. It would make more sense for a new Chinese player to base their tech on the RISC-V or Loongson architecture instead.

No company will get a licence.
AMD/Intel or both made sure VIA was railroaded into a dead end, and they were barely a rounding error in the market.

Intel and AMD are bound together forever in a marriage Intel never wanted, but AMD wrangled via AMD64.
Not to say they weren't tied before, but that was theoretically possible to escape.
They're inseparable after Intel was forced to license AMD64.
They are now so IP dependent on eachother they can never be untangled - though I suppose the older patents should expire eventually.

myne wrote on Today, 06:18:

No company will get a licence.

Intel apparently already issued a license to RosaicLabs: https://chipsandcheese.com/p/rosaiclabs-atom- … and-32-tile-amx

Granted, the license is specifically for the Atom CPUs, both those are x86 CPUs as well.

AMD/Intel or both made sure VIA was railroaded into a dead end, and they were barely a rounding error in the market. […]
Show full quote

AMD/Intel or both made sure VIA was railroaded into a dead end, and they were barely a rounding error in the market.

Intel and AMD are bound together forever in a marriage Intel never wanted, but AMD wrangled via AMD64.
Not to say they weren't tied before, but that was theoretically possible to escape.
They're inseparable after Intel was forced to license AMD64.
They are now so IP dependent on eachother they can never be untangled - though I suppose the older patents should expire eventually.

Yeah, that's how the dynamic used to be, but Intel is a lot more marginalized these days than they used to be. They are not that near-all-powerful anymore. Recently they were even teetering on bankruptcy, hoping for the US government to bail them out.

With the increasing market share of the ARM architecture, and with Apple quite successfully introducing ARM in the desktop/laptop space over these last 6 years, both Intel and AMD now have more of an incentive to encourage wider adoption of the x86 architecture, even among potential competitors.

(In the context of this reply, I meant "x86" as shorthand for x86_64/AMD64.)