31–40 of 56 posts
That project aims to reduce the effort for porting applications to run in unikernels on different platforms (Xen, KVM and baremetal).
https://lists.xen.org/archives/html/xen-devel/2017-09/msg036...
Earlier quoted context omitted.
You either run it on a single CPU or the "os" layer needs to provide for thread migration. It also obviously needs to provide thread scheduling.
Which is to say, DIY symmetric multiprocessing, or BYO kernel code in-application. I'd have to read a compelling technical explanation before believing this could perform better than a Linux or BSD kernel. In most cases, the Go code is going to be single CPU, and that ain't the way the world works anymore. There's going to be a bunch of wasted computing power on that VM
Earlier quoted context omitted.
Which is to say, DIY symmetric multiprocessing, or BYO kernel code in-application. I'd have to read a compelling technical explanation before believing this could perform better than a Linux or BSD kernel. In most cases, the Go code is going to be single CPU, and that ain't the way the world works anymore. There's going to be a bunch of wasted computing power on that VM
You can bind processing for a consistent subset of requests to an individual cpu core - essentially sharding requests across cpu cores and benefitting from very high l1 and l2 cache utilization. The idea is to treat the system with multiple cores as bunch of single cpu nodes connected via bus instead of network and without the unnecessary overhead of thread and process related context swtiching.
Earlier quoted context omitted.
I have always been fascinated by this combo. Can you discuss your use-cases and wins using this stack?
might be this or something similar, http://erlangonxen.org/
Earlier quoted context omitted.
You can bind processing for a consistent subset of requests to an individual cpu core - essentially sharding requests across cpu cores and benefitting from very high l1 and l2 cache utilization. The idea is to treat the system with multiple cores as bunch of single cpu nodes connected via bus instead of network and without the unnecessary overhead of thread and process related context swtiching.
And now you're implementing SMP in application. Zero chance of doing that as well as the Linux or bsd kernel.
Instead of sharing the code at runtime, i.e. what an OS does. You could easily share code at compile time, i.e. statically link a library.
Because of sharable code, "implementing * in application" should always be at-least as performant as the best generic implementation (i.e. the implementation you find in a general purpose OS). However, when appropriate, customizing the implementation for the application would allow it to become even more performant.
Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.
Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.
Yup, If you're running unikernels in a VM for "improved performance" you're doing it wrong. Containers are a much better solution. Unfortunately people see containers now as a packaging mechanism rather than an alternative to hardware virtualization. Also doesn't help that everyone runs their applications in The Cloud where you're required to run on a VM. I'd really like to see containers services like Joyent's take…
Interesting. I'd like to see a return to owning/renting whole machines and running containers on them directly (as several major tech companies do). A lot of the value proposition for the cloud service providers is a multi-host hypervisor that's really easy to get started with (compared to buying vSphere). If it becomes really easy to deploy your own instance of an open-source container scheduler across your own boxes, we can return to cost-competitive commodity boxes instead of overpaying for AWS.
Earlier quoted context omitted.
Yup, If you're running unikernels in a VM for "improved performance" you're doing it wrong. Containers are a much better solution. Unfortunately people see containers now as a packaging mechanism rather than an alternative to hardware virtualization. Also doesn't help that everyone runs their applications in The Cloud where you're required to run on a VM. I'd really like to see containers services like Joyent's take…
>I'd really like to see containers services like Joyent's take off. Interesting. I'd like to see a return to owning/renting whole machines and running containers on them directly (as several major tech companies do). A lot of the value proposition for the cloud service providers is a multi-host hypervisor that's really easy to get started with (compared to buying vSphere). If it becomes really easy to deploy your own…
For SMB private clouds, its a no-brainer; I just buy a FreeNAS or TrueNAS box (FreeBSD based) from iXSystems and have them customize the box for extra ram and CPU. You get ZFS, DTrace and a wicked NAS, OS level virtualization with jails and even linux binary support if required. I've done this successfully in production and could not be happier.
Note: I don't work for iXSystems but I do love their products and services.