23 ms·

In this case its the execution that was bad. If the MacOS would wake silently knowing the purpose is to scan and do nothing else, all the useless stuff for it c

In this case its the execution that was bad. If the MacOS would wake silently knowing the purpose is to scan and do nothing else, all the useless stuff for it could (and should) be kept off. Then such thing could not happen.

mschuster91 3y ago
No OS supports just waking up "specific" processes only after a resume from standby. IIRC Apple does but in a fake way - they just wake up the T2 chip and its dedicated OS, which is a ton of work to get right (as state of hardware must be coordinated between macOS and bridgeOS), and only Apple can do this because (other than servers with iLO/equivalent) no x86 machine has a similarly capable coprocessor. Edit: never mind, I must have gotten something wrong, T2 is not capable of that.
- arghwhat 3y ago
  There is no technical limitation, the kernel is free to schedule whatever it wants. The appearance that everything never stopped running is an illusion the kernel does active work to implement - heck, in the case of hibernation it is even after a normal cold boot like any other. Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective.
  - jonhohle 3y ago
    In a sleep state there is no kernel running, it’s a hardware feature that stops CPU execution and possibly more depending on the sleep state.
    - rcxdude 3y ago
      The kernel is still heavily involved in the process of going to sleep: it needs to coordinate the process, which includes freezing userspace execution. So it can quite easily unfreeze only a portion of the userspace. The main trick is making sure that the unfrozen bits aren't depending on the frozen bits, which is probably hard in general thanks to locks.
      - arghwhat 3y ago
        Userspace locks are generally per process (or process group), so it shouldn't matter. There can be IPC dependencies and file locks and what not, but none of that matters if you only run something you control and therefore can ensure have no odd dependencies.
    - arghwhat 3y ago
      Sleep states are not a switch you just flick - that be equivalent to you pulling the power cord. Even in the highest, most power hungry sleep states the kernel has to pause everything first, power down all the other hardware (otherwise you'd still have you WiFi card and GPU running full tilt), configure what will interrupt the CPU sleep and finally start it. On the other end it has to set everything back up, reinitialize all the other hardware to be in the same state as before, and finally start running user space again - pretending nothing happened even though the foundation was removed and rebuilt. The only real difference to full hibernation - where the machine is powered off entirely and the kernel restores system state from a snapshot it wrote to disk - is that the RAM state sticks around and that the CPU executes the kernel again on wake instead of dropping to the firmware boot sequence. Without that boot sequence, hibernate would basically be indistinguishable from suspend - an Phoronix article some years back talked about how Intel tuned the kernel to get from cold boot to full interactive UI in 300ms for automotive usecases.
      - MaxikCZ 3y ago
        > boot to full interactive UI in 300ms for automotive usecases. Amazing. In the meantime latest Skoda infotainments are starting up when they detect a key approaching the car to be at least somewhat ready by the time you start the car and drive. My friend states that for switching off a "simulate engine noise inside cabin" he need to let infotaintment "warm up" for another minute or two, before it becomes responsive enough to actually be able to turn that off.
  - astrange 3y ago
    > Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective. The first is rather difficult from a system perspective, because if you suspend anything you'll get deadlocks if anything else calls it, or memory growth if anything else sends IPC to it that gets buffered. You can throttle them instead, but actually suspending is hard.
    - arghwhat 3y ago
      > because if you suspend anything you'll get deadlocks if anything else calls it Processes do not call other processes, and nothing in userspace can make a (non-buggy) kernel deadlock. Processes could be waiting on IPC or user-space coordination like file locks, but we don't care about the normal user-space - our special process would not take file locks or try to IPC with other processes, as it's designed for this use-case. > or memory growth if anything else sends IPC to it that gets buffered. When you send something on a pipe, the sending process stops executing and the receiving process becomes runnable and eventually scheduled to read the data. The sending side will not get scheduled again until the receiving side completed the read. For anything buffered the same happens once the buffer fills. Nothing will grow unbounded, and behavior when other user-space applications do not run is perfectly well-defined and a constantly exercised. After all, remember that processes only get to run occasionally if at the start of a scheduling epoch the kernel feels like it, they are preempted at random mid execution, they are delayed by other things (including realtime processes that can delay other things indefinitely, higher priorities, other niceness, CPU quotas, whatnot), and so on. The idea of continuous process execution is a very, very rough illusion. What this would take is basically just something to make the scheduler disregard most processes that are technically runnable in this semi-suspend state, only picking kernel threads and specially marked processes.
- kergonath 3y ago
  > No OS supports just waking up "specific" processes only after a resume from standby. PowerNap does something like this, actually, and had been doing it for years when the T2 was introduced (since Mountain Lion, IIRC, on bog standard Intel cores).
tedunangst 3y ago
Why don't they write the rest of the OS in this guaranteed bugfree way too?

mschuster91 3y ago

No OS supports just waking up "specific" processes only after a resume from standby. IIRC Apple does but in a fake way - they just wake up the T2 chip and its dedicated OS, which is a ton of work to get right (as state of hardware must be coordinated between macOS and bridgeOS), and only Apple can do this because (other than servers with iLO/equivalent) no x86 machine has a similarly capable coprocessor. Edit: never mind, I must have gotten something wrong, T2 is not capable of that.

arghwhat 3y ago
There is no technical limitation, the kernel is free to schedule whatever it wants. The appearance that everything never stopped running is an illusion the kernel does active work to implement - heck, in the case of hibernation it is even after a normal cold boot like any other. Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective.
- jonhohle 3y ago
  In a sleep state there is no kernel running, it’s a hardware feature that stops CPU execution and possibly more depending on the sleep state.
  - rcxdude 3y ago
    The kernel is still heavily involved in the process of going to sleep: it needs to coordinate the process, which includes freezing userspace execution. So it can quite easily unfreeze only a portion of the userspace. The main trick is making sure that the unfrozen bits aren't depending on the frozen bits, which is probably hard in general thanks to locks.
    - arghwhat 3y ago
      Userspace locks are generally per process (or process group), so it shouldn't matter. There can be IPC dependencies and file locks and what not, but none of that matters if you only run something you control and therefore can ensure have no odd dependencies.
  - arghwhat 3y ago
    Sleep states are not a switch you just flick - that be equivalent to you pulling the power cord. Even in the highest, most power hungry sleep states the kernel has to pause everything first, power down all the other hardware (otherwise you'd still have you WiFi card and GPU running full tilt), configure what will interrupt the CPU sleep and finally start it. On the other end it has to set everything back up, reinitialize all the other hardware to be in the same state as before, and finally start running user space again - pretending nothing happened even though the foundation was removed and rebuilt. The only real difference to full hibernation - where the machine is powered off entirely and the kernel restores system state from a snapshot it wrote to disk - is that the RAM state sticks around and that the CPU executes the kernel again on wake instead of dropping to the firmware boot sequence. Without that boot sequence, hibernate would basically be indistinguishable from suspend - an Phoronix article some years back talked about how Intel tuned the kernel to get from cold boot to full interactive UI in 300ms for automotive usecases.
    - MaxikCZ 3y ago
      > boot to full interactive UI in 300ms for automotive usecases. Amazing. In the meantime latest Skoda infotainments are starting up when they detect a key approaching the car to be at least somewhat ready by the time you start the car and drive. My friend states that for switching off a "simulate engine noise inside cabin" he need to let infotaintment "warm up" for another minute or two, before it becomes responsive enough to actually be able to turn that off.
- astrange 3y ago
  > Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective. The first is rather difficult from a system perspective, because if you suspend anything you'll get deadlocks if anything else calls it, or memory growth if anything else sends IPC to it that gets buffered. You can throttle them instead, but actually suspending is hard.
  - arghwhat 3y ago
    > because if you suspend anything you'll get deadlocks if anything else calls it Processes do not call other processes, and nothing in userspace can make a (non-buggy) kernel deadlock. Processes could be waiting on IPC or user-space coordination like file locks, but we don't care about the normal user-space - our special process would not take file locks or try to IPC with other processes, as it's designed for this use-case. > or memory growth if anything else sends IPC to it that gets buffered. When you send something on a pipe, the sending process stops executing and the receiving process becomes runnable and eventually scheduled to read the data. The sending side will not get scheduled again until the receiving side completed the read. For anything buffered the same happens once the buffer fills. Nothing will grow unbounded, and behavior when other user-space applications do not run is perfectly well-defined and a constantly exercised. After all, remember that processes only get to run occasionally if at the start of a scheduling epoch the kernel feels like it, they are preempted at random mid execution, they are delayed by other things (including realtime processes that can delay other things indefinitely, higher priorities, other niceness, CPU quotas, whatnot), and so on. The idea of continuous process execution is a very, very rough illusion. What this would take is basically just something to make the scheduler disregard most processes that are technically runnable in this semi-suspend state, only picking kernel threads and specially marked processes.
kergonath 3y ago
> No OS supports just waking up "specific" processes only after a resume from standby. PowerNap does something like this, actually, and had been doing it for years when the T2 was introduced (since Mountain Lion, IIRC, on bog standard Intel cores).

tedunangst 3y ago

Why don't they write the rest of the OS in this guaranteed bugfree way too?