4 ms·
> According to the sources, users would need to disable E-cores I don't know the specificis of these CPUs, but it seems likely that _a sane design_ could allow
by jepler 5y ago
> According to the sources, users would need to disable E-cores
I don't know the specificis of these CPUs, but it seems likely that _a sane design_ could allow heterogeneous CPU features within a single machine.
For example, let's assume two CPU feature sets, E and P. E is a proper subset of P. Further, an E core will issue an "illegal instruction" exception when it encounters an instruction that is undefined on E and _may be_ defined on P.
Now the OS becomes free to do what it needs to do: Run a program on whatever core, E or P; but if it gets an "illegal instruction" on an E core, check the instruction; if it would be valid on the P core, mark the program (or thread or whatever) as runnable on P-cores only.
It wouldn't all work optimally on day one, but it's hardly clear that it's impossible to make it workable. There are other 'niceties' you'd want, such as the ability for applications to query the 'biggest set' and 'smallest set' of CPU feature flags.
Would it be worth the work? I'd have to classify that an open question.
- grishka 5y agoActually, iirc the Apple M1 has that x86 memory model thing on P cores only. And macOS must then only schedule x86 processes on those.
- monocasa 5y agoIt turned out that was inaccurate IIRC, and both have the TSO MSR bit.
- my123 5y agoIt wasn't inaccurate. It was true only for the Developer Transition Kit (with Apple A12X). It doesn't apply to release hardware.
- monocasa 5y agoTo be fair, an M1 isn't a A12X. But of course you're totally right, and it's great to finally know the etymology of this particular misunderstanding.
- BeeOnRope 5y agoAlthough this comes up a half dozen times every time hybrid CPUs and AVX-512 is mentioned, it is not so simple when considering existing x86 software. Most [1] well-behaved software doesn't simply execute AVX-512 instructions (or any other recent ISA) to see what happens (this would just crash on any non-AVX-512 host), rather they query the ISA capabilities (via CPUID) and if AVX-512 support is reported, they'll use it. So in your proposal, you need to decide what CPUID is going to report: does it report AVX-512 support, or not? Does it report differently depending on what CPU the CPUID instruction happens to run on? The latter option is a non-starter, because (a) it doesn't make sense and (b) the implied ABI is that CPUID ISA support won't change over the lifetime of a process. So you are left with reporting AVX-512 on all cores, or none. If you report it on all cores, most processes will execute AVX-512, by the route of a few libc functions which are optimized to use the widest ISA available: so almost everything will end up pinned on the P cores, even if they get little benefit from it. OTOH if you report no AVX-512 support, well-behaved processes won't execute AVX-512 and trigger your dynamic migration in the first place. Now you can imagine a greenfield where processes are aware of the hybrid nature of CPUs and then things might play out differently: but then you don't need the dynamic migration mechanism at all: since they are aware of what's going on, just have the processes hint to the OS where they should run. --- [1] One exception is software compiled for a specific target ISA, e.g., -march=avx-512f or whatever. In this case the hybrid system kind of works: you compile your stuff that way if you want it to run on the big cores only, or with a lower-tier ISA if you want it to run everywhere. So it's like an opt-in to big cores w/o having to mess with affinity or other OS hinting.