FreeBSD ULE scheduler on E-cores

Just wondering, what is the current state of FreeBSD ULE scheduler for modern (Intel) chips containing E-cores?
Is the support already there, planned for 14.0 or still under construction?
 
What kind of support are you talking about? If you have technical details and want technical answer, ask this on current@/hackers@.
 
Phoronix briefly discussed that situation three months ago: https://www.phoronix.com/news/BSDs-On-Intel-Raptor-Lake

Raptor Lake (and prior gen Alder Lake) is all the more challenging with the BSDs due to Intel's hybrid architecture and Thread Director. I am not aware of any BSD yet having support for Intel's hybrid core handling for proper task placement between the P and E cores. Many of the BSDs are also behind in their security mitigation handling compared to the Linux kernel. In any event I went ahead and downloaded the latest BSD images and proceeded to see how they would work out on this latest Raptor Lake desktop.

After three failed boots, to much surprise, OpenBSD 7.2 had booted fine on the Core i9 13900K system! OpenBSD booted on Raptor Lake! But then when proceeding with the installer, the wired and wireless networking for this ASUS Z790 motherboard were not working on this latest OpenBSD release. Thus resorting to an older USB network adapter to have a network connection. But at least OpenBSD did succeed where FreeBSD/DragonFlyBSD/NetBSD failed.


I suspect FreeBSD 14.0 may still not have proper support for Raptor Lake and Alder Lake at release, as the release notes say nothing about it:
 
(Phoronix) Many of the BSDs are also behind in their security mitigation handling compared to the Linux kernel
They mean behind fixing the bugs intel et al introduced into their silicon to cut corners in pursuit of higher performance? Yes, that's a reason...
 
Voltaire already pointed it out: Alder Lake is still some way out for FreeBSD. 14 boots fine on 12th gen Intel computers, but integrated graphics is certainly still in ongoing development. There's been some progress, but Intel is more and more pushing into proprietary binary firmware blobs doing their thing. That makes debugging and troubleshooting even more painful.

Thus, I'm hopeful that 14 will run fine on Alder Lake once it releases but there will be room for improvement in terms of using P/E cores for their intended purpose. Right now, on a 12th gen Intel with P and E cores, it simply treats all cores the same, at least as far as I know - would have to check commit logs to be 100% certain.

Also, in drm-kmod, pxp is disabled for i915 at the moment and we probably won't see that in a while, because there's more pressing issues to be resolved beforehand.
 
They mean behind fixing the bugs intel et al introduced into their silicon to cut corners in pursuit of higher performance? Yes, that's a reason...
THIS.


I also always wonder what they are doing at phoronix to always get such weird "results", also they still don't seem to have understood what -RELEASE and -CURRENT are and bragging about what brand-new hardware isn't supported in RELEASE.
Also my Alder Lake laptop booted up just fine with 13.1-RELEASE and I only used 13.2-beta (meanwhile upgraded to R2) to set it up to get/test i915 driver support for the integrated GPU (works, but graphics output on XFCE freezes after a while so I'm using the modesetting driver for now) and the updated AX211 driver (seems to work, but I'm always using wired LAN anyways...).

True, linux supports almost every new and exotic hardware shortly after release - but usually a lot of those initial drivers are garbage and far from something you could consider 'production ready'. Something like that doesn't belong in any -RELEASE. I'd rather wait a few weeks/months to get something that actually works than having to deal with kernel panics, firmware lockups and other annoyances. If I'm ok whit those possible problems and absolutely *want* some new hardware fully supported, I'd just go for CURRENT.

And about the P- and E-Cores: I couldn't care less. that CPU (i71255U) uses ~4W during normal workloads, so I highly doubt there is that much to gain to justify making working on that a priority.
 
Back
Top