Hacker News Reader

Comment by caspper69 | Hacker News Reader

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.

View on HN

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)

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.

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.

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.

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.

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.

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.

Less fat in OS layers, thus reducing the total resources per image.

But if the images are unique you now have N instances to manage... when the dependencies are strongly coupled!

Just like Docker images that everyone around here loves so much.

Where do most of the container users deploy their containers? Would you say they are on the public cloud which is inherently virtualized to begin with?

A lot of people that have not deployed unikernels might not be aware of how they are actually deployed. When we deploy our websites and database and such to something like Google or AWS we upload a disk image. That disk image is then converted into a machine image. On AWS that would be an AMI. Then we boot that AMI and that AMI only contains your program. There is no underlying linux that you deploy and then you ssh into and install some k8s substitute.

So, yes, in comparison to launching a linux instance on AWS or Google, then installing k8s or using nomad or something like that, that has to inherently duplicate networking, duplicate storage, duplicate security, and many other things - yes it reduces quite a lot. This doesn't even touch on the fact that many unikernels tend to run much faster for other reasons. We are just talking about not having to use things like underlay/overlay networks or storage proxies.

Again, the images that are deployed get managed by the cloud of choice - so your networking, storage, security, etc. is all managed by that cloud.

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.

"reduces efficiency and increases complexity". Sorry there.

All that's old is new again. A mentor taught me this.

I've seen myself that with embedded and web sites.

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

> People want DOS

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

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).

Talking about the docker practice, which we already had with gentoo hardened with linux vserver.

> 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.

Reply on news.ycombinator.com