4 ms·

So true, my experience with the BIG.little ARM platform and a regular Linux kernel is that you always end up with the wrong scheduling and the system underperfo

So true, my experience with the BIG.little ARM platform and a regular Linux kernel is that you always end up with the wrong scheduling and the system underperforms because it uses the little CPU for a compute-intensive single-thread task… I'll just avoid these kind of systems.

linuxhansl 4y ago
I thought that was fixed with Kernel 5.15.35 https://www.phoronix.com/scan.php?page=article&item=linux-51535-adl&num=1 https://www.phoronix.com/scan.php?page=article&item=linux-51... Did you have this kernel, or an earlier one? (Perhaps there're still many problems to fix)
urthor 4y ago
"What Andy giveth, Bill Taketh away." Big little is fundamentally the correct architecture. It's not Intel's fault that the software guys making the Linux Kernel haven't fully supported heterogeneous yet. In the long term, it'll be the optimal call for so many workloads. Thousands of server and laptop workloads care only about performance per watt, not peak single thread.
- Traster 4y ago
  It's true that the software kills the theoretical performance that the hardware makes available. But I actually think this is an indictment of hardware not software engineers. It's basically "We've created this incredibly difficult problem for you, good luck" from the hardware engineers. How the hell is the OS meant to know whether this thread is going to turn out to be a rendering operation or a logging thread? With these architectures I think often what the management should really look at is: "We currently employ 100 hardware engineers, and 30 software engineers, with this architecture, we're going to need 50 hardware engineers and 500 software engineers. Do we still think this is the right call?"
  - urthor 4y ago
    "How the hell is the OS meant to know whether this thread is going to turn out to be a rendering operation or a logging thread?" Because this problem is incredibly well solved (I believe?). Scheduling priorities in operating systems an enormously well explored topic. Put simply: you must incorporate heterogenous cores into the OS thread scheduler. There's three actors here: Hardware developers. OS developers. End user software engineers. The hardware developers are running into physical constraints. The fix is to shift the prioritisation between the different core types, big little, to the operating system scheduler.

linuxhansl 4y ago

I thought that was fixed with Kernel 5.15.35 https://www.phoronix.com/scan.php?page=article&item=linux-51535-adl&num=1 https://www.phoronix.com/scan.php?page=article&item=linux-51... Did you have this kernel, or an earlier one? (Perhaps there're still many problems to fix)

urthor 4y ago

"What Andy giveth, Bill Taketh away." Big little is fundamentally the correct architecture. It's not Intel's fault that the software guys making the Linux Kernel haven't fully supported heterogeneous yet. In the long term, it'll be the optimal call for so many workloads. Thousands of server and laptop workloads care only about performance per watt, not peak single thread.

Traster 4y ago
It's true that the software kills the theoretical performance that the hardware makes available. But I actually think this is an indictment of hardware not software engineers. It's basically "We've created this incredibly difficult problem for you, good luck" from the hardware engineers. How the hell is the OS meant to know whether this thread is going to turn out to be a rendering operation or a logging thread? With these architectures I think often what the management should really look at is: "We currently employ 100 hardware engineers, and 30 software engineers, with this architecture, we're going to need 50 hardware engineers and 500 software engineers. Do we still think this is the right call?"
- urthor 4y ago
  "How the hell is the OS meant to know whether this thread is going to turn out to be a rendering operation or a logging thread?" Because this problem is incredibly well solved (I believe?). Scheduling priorities in operating systems an enormously well explored topic. Put simply: you must incorporate heterogenous cores into the OS thread scheduler. There's three actors here: Hardware developers. OS developers. End user software engineers. The hardware developers are running into physical constraints. The fix is to shift the prioritisation between the different core types, big little, to the operating system scheduler.