5 ms·

I love it. We spent 30 years getting preemptive-multitasking working, and it is such a giant fragile pain in the a, that it is easier to just virtualize the wh

I love it. We spent 30 years getting preemptive-multitasking working, and it is such a giant fragile pain in the a, that it is easier to just virtualize the whole damn computer rather than making different software play nice together (maybe run well together is more apropos). We have now come full circle. People want DOS. I have officially lived "long enough." Not too long, mind you, just long enough.

jonjacky 6y ago
it is easier to just virtualize the whole damn computer IBM did this starting in the 1960s as a way of providing time-sharing. It became their VM/CMS OS product line (VM - hypervisor, CMS - single-user guest OS - but any OS could be the guest, including VM itself) CMS influenced the CP/M microcomputer operating system. So yes, it was not unlike DOS. https://en.wikipedia.org/wiki/VM_(operating_system) https://en.wikipedia.org/wiki/VM_(operating_system)
rwmj 6y ago
I've never thought that preemptive multitasking is "such a giant fragile pain in the a". I think it's pretty useful. What has been the problem with it? We could probably do with partitioning the desktop though, but that's easily done with a bit more cgroups.
- caspper69 6y ago
  The biggest problem is that context switching overhead becomes the main "work" being done, rather than the actual work of the threads, for some core count n (which depends on workload). You can already saturate an entire core just copying data from a NIC. Of course, enter BPF and all that jazz. Plus it doesn't play as nice with BIG.little multiprocessing (AMP - asymmetric multiprocessing). edit: I should note I am not advocating getting rid of preemption entirely, because it is needed for at least one processor, but having a fixed quantum causing a context switch on application CPUs is highly disruptive, both from the operation itself, and from blowing the cache all the time. Incidentally, one of the main reason for green threads.
- jandrewrogers 6y ago
  One modern systems, preemptive multitasking has a surprisingly high overhead. Much of your CPU time can be spent on context switching and the associated cache thrashing, which isn't productive. Furthermore, many kinds of macro-optimizations based on temporal locality stop working because preemption can randomly inject badly chosen computation into your carefully crafted computational sequencing. Preemptive multitasking makes it more difficult to ensure robustness under load generally because the default behavior of the system is that it will happily do the wrong thing at the wrong time under stress, because the OS has no idea what the right thing is, which can aggravate the situation. Obviously, none of this applies to systems that are typically under light-to-modest load. For servers with hardware capable of very high bandwidth I/O, preemptive multitasking is a major drag on performance and scalability. Hence why "thread-per-core" software architectures are idiomatic for high-performance data infrastructure software these days. You don't just gain significant absolute performance, the behavior can also degrade more gracefully under extreme load. Like with all things, it depends on what you are doing. I've designed database engines both ways and Linux is not opinionated about such things.
angry_octet 6y ago
So how do you schedule them now they are VM threads contending for cores? This doesn't change that problem at all. The gains are in security (reducing complexity and attack surface) and packaging. However, it uses coarse isolation with a single process model, so you would be compelled to isolate via many vm processes, which pushes the security/isolation management up to the container level and can incur a performance penalty.
- eyberg 6y ago
  You use the native cloud facilities available by spinning up a new instance per deploy. Whether you need a simple shared thread (smallest instances available) or you want to tackle the 368 thread monsters available on something like GCloud both are fine. It's worth pointing out that if you run containers on public cloud you are inherently virtualized already - this actually removes layers instead of adding layers on.
  - angry_octet 6y ago
    Theoretically you are renting 100% of a virtual core (whatever fraction of a real core that is depends on the hardware you're scheduled on at that moment), but in practice you're sharing cycles at small core counts. But anyway, if you spawn 8 instances each with 2 cores you're not getting any more compute than 16 cores on the same box. You could schedule them with cpuset to have 2 cores per process, or you could let the scheduler run. But there is no free lunch from the cloud. I have no idea why you think running on N images reduces overhead.
    - pjmlp 6y ago
      Less fat in OS layers, thus reducing the total resources per image.
      - angry_octet 6y ago
        But if the images are unique you now have N instances to manage... when the dependencies are strongly coupled!
MrBuddyCasino 6y ago
> People want DOS People want Docker. Solves packaging, resource management and isolation. They don’t want unikernels, or it would have happened already.
- still_grokking 6y ago
  Docker is dead. (OK, to be fair, it's still in the process of dying). As Docker don't solve isolation you need to run Docker in VMs anyway, so actually people start to think how to get rid of this unnecessary overhead. The foreseeable future are microVMs (the hype is just heating, projects show up "everywhere"). And in the long run unikernels could become the "packaging format" for those microVMs (but they have to mature first as ease of use, und performance / stability are not there right now).
  - 1337shadow 6y ago
    Talking about the docker practice, which we already had with gentoo hardened with linux vserver.
  - MrBuddyCasino 6y ago
    > Docker is dead Replace "Docker" with "containers" then. > but they have to mature first as ease of use, und performance / stability are not there right now And this is what I have a hard time seeing. Unikernels had their hype moment several years ago, and nothing has happened in the meantime. If there is no big leap in tooling, lightweight virtualisation will remain a transparent implementation detail for the cloud vendors.
    - bcrl 6y ago
      I stand by my statement that Docker is static linking for millennials.
      - MrBuddyCasino 6y ago
        Yup. Also, Kubernetes is application server for millennials.
cbsmith 6y ago
OSv has preemptive multi-tasking. Unikernels are more about having your application run in kernelspace, and recognizing that in distributed computing contexts, individual computers tend to be only doing one thing, and having them doing other things reduces efficiency and decreases complexity.
- cbsmith 6y ago
  "reduces efficiency and increases complexity". Sorry there.
macjohnmcc 6y ago
This is one of those stay off my lawn moments but involving computer resources.
adultSwim 6y ago
All that's old is new again. A mentor taught me this. I've seen myself that with embedded and web sites.

jonjacky 6y ago

it is easier to just virtualize the whole damn computer IBM did this starting in the 1960s as a way of providing time-sharing. It became their VM/CMS OS product line (VM - hypervisor, CMS - single-user guest OS - but any OS could be the guest, including VM itself) CMS influenced the CP/M microcomputer operating system. So yes, it was not unlike DOS. https://en.wikipedia.org/wiki/VM_(operating_system) https://en.wikipedia.org/wiki/VM_(operating_system)

rwmj 6y ago

I've never thought that preemptive multitasking is "such a giant fragile pain in the a". I think it's pretty useful. What has been the problem with it? We could probably do with partitioning the desktop though, but that's easily done with a bit more cgroups.

caspper69 6y ago
The biggest problem is that context switching overhead becomes the main "work" being done, rather than the actual work of the threads, for some core count n (which depends on workload). You can already saturate an entire core just copying data from a NIC. Of course, enter BPF and all that jazz. Plus it doesn't play as nice with BIG.little multiprocessing (AMP - asymmetric multiprocessing). edit: I should note I am not advocating getting rid of preemption entirely, because it is needed for at least one processor, but having a fixed quantum causing a context switch on application CPUs is highly disruptive, both from the operation itself, and from blowing the cache all the time. Incidentally, one of the main reason for green threads.
jandrewrogers 6y ago
One modern systems, preemptive multitasking has a surprisingly high overhead. Much of your CPU time can be spent on context switching and the associated cache thrashing, which isn't productive. Furthermore, many kinds of macro-optimizations based on temporal locality stop working because preemption can randomly inject badly chosen computation into your carefully crafted computational sequencing. Preemptive multitasking makes it more difficult to ensure robustness under load generally because the default behavior of the system is that it will happily do the wrong thing at the wrong time under stress, because the OS has no idea what the right thing is, which can aggravate the situation. Obviously, none of this applies to systems that are typically under light-to-modest load. For servers with hardware capable of very high bandwidth I/O, preemptive multitasking is a major drag on performance and scalability. Hence why "thread-per-core" software architectures are idiomatic for high-performance data infrastructure software these days. You don't just gain significant absolute performance, the behavior can also degrade more gracefully under extreme load. Like with all things, it depends on what you are doing. I've designed database engines both ways and Linux is not opinionated about such things.

angry_octet 6y ago

So how do you schedule them now they are VM threads contending for cores? This doesn't change that problem at all. The gains are in security (reducing complexity and attack surface) and packaging. However, it uses coarse isolation with a single process model, so you would be compelled to isolate via many vm processes, which pushes the security/isolation management up to the container level and can incur a performance penalty.

eyberg 6y ago
You use the native cloud facilities available by spinning up a new instance per deploy. Whether you need a simple shared thread (smallest instances available) or you want to tackle the 368 thread monsters available on something like GCloud both are fine. It's worth pointing out that if you run containers on public cloud you are inherently virtualized already - this actually removes layers instead of adding layers on.
- angry_octet 6y ago
  Theoretically you are renting 100% of a virtual core (whatever fraction of a real core that is depends on the hardware you're scheduled on at that moment), but in practice you're sharing cycles at small core counts. But anyway, if you spawn 8 instances each with 2 cores you're not getting any more compute than 16 cores on the same box. You could schedule them with cpuset to have 2 cores per process, or you could let the scheduler run. But there is no free lunch from the cloud. I have no idea why you think running on N images reduces overhead.
  - pjmlp 6y ago
    Less fat in OS layers, thus reducing the total resources per image.
    - angry_octet 6y ago
      But if the images are unique you now have N instances to manage... when the dependencies are strongly coupled!

MrBuddyCasino 6y ago

> People want DOS People want Docker. Solves packaging, resource management and isolation. They don’t want unikernels, or it would have happened already.

still_grokking 6y ago
Docker is dead. (OK, to be fair, it's still in the process of dying). As Docker don't solve isolation you need to run Docker in VMs anyway, so actually people start to think how to get rid of this unnecessary overhead. The foreseeable future are microVMs (the hype is just heating, projects show up "everywhere"). And in the long run unikernels could become the "packaging format" for those microVMs (but they have to mature first as ease of use, und performance / stability are not there right now).
- 1337shadow 6y ago
  Talking about the docker practice, which we already had with gentoo hardened with linux vserver.
- MrBuddyCasino 6y ago
  > Docker is dead Replace "Docker" with "containers" then. > but they have to mature first as ease of use, und performance / stability are not there right now And this is what I have a hard time seeing. Unikernels had their hype moment several years ago, and nothing has happened in the meantime. If there is no big leap in tooling, lightweight virtualisation will remain a transparent implementation detail for the cloud vendors.
  - bcrl 6y ago
    I stand by my statement that Docker is static linking for millennials.
    - MrBuddyCasino 6y ago
      Yup. Also, Kubernetes is application server for millennials.

cbsmith 6y ago

OSv has preemptive multi-tasking. Unikernels are more about having your application run in kernelspace, and recognizing that in distributed computing contexts, individual computers tend to be only doing one thing, and having them doing other things reduces efficiency and decreases complexity.

cbsmith 6y ago
"reduces efficiency and increases complexity". Sorry there.

macjohnmcc 6y ago

This is one of those stay off my lawn moments but involving computer resources.

adultSwim 6y ago

All that's old is new again. A mentor taught me this. I've seen myself that with embedded and web sites.