Although 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.
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.