IIRC, AlderLake had several variants. And differences in having AVX512 or not within p- and e- cores could be fatal difference for apps which mandates AVX512 on build.The e-cores and p-cores are completely identical from a x86_64 application's point of view. If they were not, they could not be preempted while running on a p-core and rescheduled to continue running on an e-core, which isn't just what e-core/p-core unaware FreeBSD is having them do all the time, and all other operating systems were also doing when the AlderLake was released, it's also what the chip is designed to do: Most applications (threads) cause burst load every now and then become idle or do minor tasks waiting for more work to be provided to them, and the OS scheduler can analyze a machine specific register to acquire the information whether the CPU's microcode considers a thread worthy of being migrated to the other efficiency level or not, but processing this MSR is optional.
Where's the "Atom" coming from? Each of my Emerald Rapids' E-Cores outperforms a Skylake SP Core, and that's with AVX512 code, which Atoms don't support. According tho intel's slides, the main difference between the e-cores and the p-cores is the number of vector co-processors, where the e-cores have 1 and the p-cores have 3 co-processors. Which makes sense as the detection and distribution of out-of-band executable vector code to the available vector co-processors is done by the instruction pipeline optimizer, which is invisible to x86_64 applications, so x86_64 applications have no means to know how many co-processors are present or are being used, allowing for this number to change at runtime. Intel has also had trouble with the excessive power consumption and heat generation of their vector co-processors ever since they introduced AVX2, while most applications even now, i.e. a decade later, do not use AVX to all during their lifetime. So reducing the number of high AVX performance capable cores allows most applications to run at the same performance while selected applications can now run faster on a performance cores that has additional co-processors: All Xeon Silver 44xx/45xx have only p-cores, while the Gold 54xx/55xx/64xx/65xx have most cores being e-cores and most Golds have less p-cores then their Silver "competitors", but outside of microbenchmarking, the Golds outperform the Silvers in work/time, and even more so in work/watt, i.e. have better TCOO and efficiency.
So schedulers SHALL be 100% aware of the cores, strictly speaking.
But why FreeBSD base and apps not affected?
Simply because AVX512 is usually not enabled by default.
Note that if some apps that auto-detect allocated cores on its startup could crash if initially allocated p-cores (unpinned) but at some point moved to e-cores.