3 ms·
Looks like it's just about collecting stats on whether code "partitions" executed the way the (new) predictor thought it would, and if it didn't it, suggests to
by tommiegannert 3y ago
Looks like it's just about collecting stats on whether code "partitions" executed the way the (new) predictor thought it would, and if it didn't it, suggests to the OS to move the load to another type of core.
I doubt this would break anything except possibly performance regressions in tightly optimized code that's been tailored to very specific CPU HT behavior.
From a cursory glance, it seems like an obvious thing to do now that there are cores of different types (Efficiency and Performance). Just like deciding at which level to cache something, when caches became hierarchies.
Edit: BTW, when we have FPGAs as another type of "core", it'll be cool to see if the OS can decide to not only schedule code on that subsystem, but also select a completely different instruction set ("bit stream") for that section of code. Would require a true "multi-architecture" binary, with the OS deciding "architecture" for individual code partitions depending on what other processes are running on the machine.
- wmf 3y agowhen we have FPGAs as another type of "core" This isn't going to happen because FPGAs are too area-inefficient.