4 ms·

> or even kernel daemons run on the efficiency cores When (not if) the kernel scheduler locks up while the fans are slow/stopped at the same moment some schedu

> or even kernel daemons run on the efficiency cores When (not if) the kernel scheduler locks up while the fans are slow/stopped at the same moment some scheduled user process begins driving 250W+ through a CPU the isolated fan controller (not to mention isolated thermal throttling logic, also independent of the OS) has great value. > If this doesn’t happen—why doesn’t it? Hardware evolves faster than operating systems and has complex requirements of which operating systems are oblivious, and there is no world where device manufacturers and consumers will tolerate being gated on operating system evolution. These complications have to run somewhere so independent processing elements appear and grow. This pattern delivers ever crucial compatibility by hiding new complications from legacy operating system interfaces. The only path I can imagine that would change this paradigm requires a.) greatly increasing the reliability and security of operating systems to the point where they can be trusted not to fail and damage hardware or corrupt things and b.) generalizing all known and future hardware and operating system interfaces such that hardware drivers (which, due to the more rapid evolution of hardware, do not enjoy the long term maintenance cycle of operating systems) can be highly portable, both across platforms and forward. Both of these requirements are "Hard" as in we have only begun to achieve this in primordial ways.

derefr 3y ago
You don’t seem to be paying attention to the words “vertically integrated” in my question — which were the whole point of my question. Apple creates both the OS and the hardware for their phones. So why shouldn’t the hardware microcontroller firmware for the hardware they create (or commission and constrain the design of), run as one or several RTOS blobs that ship as part of the OS on one or several shared MCUs? Let me put it this way: in x86, the motherboard has a power controller, but the CPU also has its own power controller. But on a vertically-integrated SoC system, I would expect there to be only one power controller, that controls power for the CPU, the other cores on the SoC die, and the various other components on the logic board. And I would expect that power controller, whether standalone or integrated into the CPU, to be running first-party code written by the system integrator (who is also the designer of the logic board, the SoC, the CPU in the SoC, and the power controller itself) rather than running code written by some vendor who was writing it in a “this chip could be used in many different builds, so it must be designed defensively for badly-integrated systems” manner.
- deleted 3y ago
  [deleted]
- rcxdude 3y ago
  One thing is that even in a vertically integrated company you don't necessarily have great communication between the teams responsible for one part or another. And so if there's not a great technical push for it, it can still make sense to have a bunch of silos to simplify the interfaces between different parts of the system.
- topspin 3y ago
  > You don’t seem to be paying attention to the words “vertically integrated” in my question That's because vertical integration doesn't actually solve the core problems.
rcxdude 3y ago
The M1 mac laptops have gone partway in this direction, though they still have a great deal running as firmware: the speaker drivers can drive a lot of power into the speakers in order to get better and louder sound, but this opens up the possibility of a particularly aggressive waveform damaging the speakers from overheating. The OS is responsible for ensuring that this doesn't happen by modelling the power dissipated in the speakers and limiting the power when they are likely to be getting too hot.

derefr 3y ago

You don’t seem to be paying attention to the words “vertically integrated” in my question — which were the whole point of my question. Apple creates both the OS and the hardware for their phones. So why shouldn’t the hardware microcontroller firmware for the hardware they create (or commission and constrain the design of), run as one or several RTOS blobs that ship as part of the OS on one or several shared MCUs? Let me put it this way: in x86, the motherboard has a power controller, but the CPU also has its own power controller. But on a vertically-integrated SoC system, I would expect there to be only one power controller, that controls power for the CPU, the other cores on the SoC die, and the various other components on the logic board. And I would expect that power controller, whether standalone or integrated into the CPU, to be running first-party code written by the system integrator (who is also the designer of the logic board, the SoC, the CPU in the SoC, and the power controller itself) rather than running code written by some vendor who was writing it in a “this chip could be used in many different builds, so it must be designed defensively for badly-integrated systems” manner.

deleted 3y ago
[deleted]
rcxdude 3y ago
One thing is that even in a vertically integrated company you don't necessarily have great communication between the teams responsible for one part or another. And so if there's not a great technical push for it, it can still make sense to have a bunch of silos to simplify the interfaces between different parts of the system.
topspin 3y ago
> You don’t seem to be paying attention to the words “vertically integrated” in my question That's because vertical integration doesn't actually solve the core problems.

rcxdude 3y ago

The M1 mac laptops have gone partway in this direction, though they still have a great deal running as firmware: the speaker drivers can drive a lot of power into the speakers in order to get better and louder sound, but this opens up the possibility of a particularly aggressive waveform damaging the speakers from overheating. The OS is responsible for ensuring that this doesn't happen by modelling the power dissipated in the speakers and limiting the power when they are likely to be getting too hot.