Hacker News Reader

Comment by andrewstuart2 | Hacker News Reader

Containers are not about safety or lightness IMO. Rather, the reasons I prefer them are better insight and usability. Since the same kernel is running multiple applications, it has insight into how much RAM has been requested, and how much CPU is being used, and can thus be more efficient in packing processes onto nodes. If you try to build this with unikernels, you will end up turning your hypervisor into a de facto kernel. As it is, hypervisors simply preallocate resources and in pretty much every case must overprovision for peak usage, which requires more unused capacity.

As for usability, I mean that you get many of the benefits of VMs (namespaces and resource constraints), but still with the added benefit of the kernel introspection.

View on HN

> it has insight into how much RAM has been requested

Most VM hypervisors have this insight as well, as long as the guest is running at least slightly paravirtualized (i.e. has a "memory balloon" driver.)

I think what you describe most people lump into the "lightweight" characterization.

Under that definition, then, VMs would not be lighter than containers, because they require overprovisioning and don't (by deliberate design) dynamically communicate memory or CPU usage to the hypervisor.

Linux supports hot-adding memory. Since it can do that, as a guest, so can any other VM. Overprovisioning might be required, but it's only required because of software limitations, not by hardware. I would venture a guess that could be solved.

Hot-adding memory is essentially have the equivalent of the mmap kernel syscall, but there's no ability for the VMs to return memory that they no longer need, as you have with the munmap syscall. So you may start out without overprovisioning, but eventually you will hit peak hours, redistribute your VMs, and be overprovisioned again unless you reboot machines after peak hours.

Even if you did add a capability to compact and dynamically stop using hardware memory into linux, then signal the hardware layer that it's not used, you're again just implementing another feature provided by standard kernels for decades. Not to mention this feature seems basically coupled to virtualized hardware.

The kernel can unmap memory by having a special "ballooning" driver that "allocates" memory pages returned to the hypervisor. I'm pretty sure that every sane hypervisor supports it since ages.

You can take memory from the VM. I've just tested it on KVM, dropping the current memory allocation for a vm, and reraising it. Shows up in free in the vm instantly.

Well it sounds like that is possible, but is there any way for the VM to indicate to the hypervisor that there is unused memory? Or for that fact, that it needs more? That's the critical missing piece, unless there's an API I'm unaware of.

I suppose this question should be posed on a linux kernel mailing list somewhere.

Reply on news.ycombinator.com