Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My First Unikernel

roscidus.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: My First Unikernel

#41

Post by 616c »

avsm wrote: post #34
616c wrote: post #7

So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime. If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?

Two answers: scaling through structured distributed systems abstractions is a key aim in Mirage. We deliberately want each VM to be predictable, single vCPU and scale via multiple VMs. It's far more efficient to scale via lots of small VMs that are scheduled independently than having a few big multicpu VMs (which have a lot of overhead since the CPU sync also needs to be virtualised). See our ASPLOS 2013 paper for so…

More on point:

So I am understanding correctly message passing will most likely by the paradigm you encourage?

And, less on point:

> Other answer: we will be talking about our multicore ocaml implementation at ICFP in September. I still don't want to see it in Mirage though :-)

Wait what what what? So it is ready for prime-time? (Note, I did not say production.) I remember reading about it on Jane Street, but thought there will still proposals and lots of theoretical and planning wrinkles to iron out before an implementation became reality.

I do not want to derail this informative post by you anymore, but do you have a link to more on that topic?

And I remember seeing mention of Irmin and not getting how ti fit into your work, asvm. Now seeing it as an answer to my question makes sense.

And thanks for your work on Real World Ocaml. I have decided to get back into programming, and some of my co-workers were taking CS classes and systems programming (ironically Harvard Extension School, I can't afford it but good for them) used OCaml. This reminded me to come take a look and I find your book, and the OCaml resurgence fascinating.

Maybe one done, I will look at the Haxe compiler and go: "it is not so complicated, I get that now." Only in OCaml could I see people doing such crazy shit.

Re: My First Unikernel

#42

Post by nimish »

amirmc wrote: post #16
enduser wrote: post #5

If it helps to add clarity to what this is about, Xen still requires a host (dom0) operating system, usually Linux but also NetBSD and OpenSolaris. Mirage OS (the basis for building your own unikernel) allows building applications as domU kernels. This is advantageous because it minimizes context-switching and allows all of the code in a Xen VM (domU) to be written in a safer language than C. So the dom0 OS (Linux) s…

Even if you have your own hardware there are scenarios where you might want stronger isolation, increased density and/or heterogeneous deployments. All of which is achievable with Unikernels running on Xen.

Sure but then I'm limited to OCaML and have to run in kernel mode when developing apps.

Occasionally a good tradeoff, but a significant one.

Re: My First Unikernel

#43

Post by amirmc »

616c wrote: post #41
avsm wrote: post #34

Earlier quoted context omitted.

Two answers: scaling through structured distributed systems abstractions is a key aim in Mirage. We deliberately want each VM to be predictable, single vCPU and scale via multiple VMs. It's far more efficient to scale via lots of small VMs that are scheduled independently than having a few big multicpu VMs (which have a lot of overhead since the CPU sync also needs to be virtualised). See our ASPLOS 2013 paper for so…

More on point: So I am understanding correctly message passing will most likely by the paradigm you encourage? And, less on point: > Other answer: we will be talking about our multicore ocaml implementation at ICFP in September. I still don't want to see it in Mirage though :-) Wait what what what? So it is ready for prime-time? (Note, I did not say production.) I remember reading about it on Jane Street, but thought…

> ... do you have a link to more on that topic?

The following may be of interest [1]. There's been more progress since and we'll be talking about it at OCaml 2014 [2].

[1] http://www.cl.cam.ac.uk/~sd601/multicore.md

[2] http://ocaml.org/meetings/ocaml/2014/program.html

Re: My First Unikernel

#44

Post by amirmc »

n0body wrote: post #28
rjsw wrote: post #26

Earlier quoted context omitted.

There is nothing stopping people from implementing something similar in other languages. The developer using this doesn't need to know anything about Xen, they just see a single address space system that runs their code.

i didn't say there was, but it's still complicating the task. i'm not saying it isn't cool, but it's a very round about way of doing something, and as such it becomes more expensive in development time and skill required

More roundabout than the current paradigm of duplicate Linux stacks and supporting services for DevOps just to get stuff deployed? That doesn't make sense to me.

Your argument is actually "It seems very new. Not enough people know/use it. Therefore, I won't use it." -- which is fine, but please don't mischaracterise it in terms of increased complexity or expense.

Re: My First Unikernel

#45

Post by lucian1900 »

paulasmuth wrote: post #6

This sounds like an awesome and fun project to hack on! However, optimizing around context switches and task preemptions is something you would usually do if your application is actually bound by IO/context switching, is extremely latency sensitive or when you are trying to squeeze the last bits of performance out of a machine. Why did you choose to build such a microoptimized system in a garbage collected language?…

> You'd get proper error handling and a good type system

Except you wouldn't, which is a major reason to not use C++.

Re: My First Unikernel

#46

Post by amirmc »

nimish wrote: post #42
amirmc wrote: post #16

Earlier quoted context omitted.

Even if you have your own hardware there are scenarios where you might want stronger isolation, increased density and/or heterogeneous deployments. All of which is achievable with Unikernels running on Xen.

Sure but then I'm limited to OCaML and have to run in kernel mode when developing apps. Occasionally a good tradeoff, but a significant one.

There are other approaches that yield Unikernels [1]. I don't quite understand your point about kernel mode and why that would be a problem under this scenario. The code is your own and you only use the OS components you require. The ASPLOS article has more detail on the approach and trade-offs [2].

[1] see table 2 at http://queue.acm.org/detail.cfm?id=2566628

[2] http://anil.recoil.org/papers/2013-asplos-mirage.pdf

Re: My First Unikernel

#49

Post by n0body »

amirmc wrote: post #44
n0body wrote: post #28

Earlier quoted context omitted.

i didn't say there was, but it's still complicating the task. i'm not saying it isn't cool, but it's a very round about way of doing something, and as such it becomes more expensive in development time and skill required

More roundabout than the current paradigm of duplicate Linux stacks and supporting services for DevOps just to get stuff deployed? That doesn't make sense to me. Your argument is actually "It seems very new. Not enough people know/use it. Therefore, I won't use it." -- which is fine, but please don't mischaracterise it in terms of increased complexity or expense.

My argument is that you'll need better developers who cost more money. Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug. and you've also got the added overhead of running xen.

all in all it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms, since you get the bare metal, and a little bit of a environment to bootstrap from.

Re: My First Unikernel

#50

Post by lmm »

n0body wrote: post #49
amirmc wrote: post #44

Earlier quoted context omitted.

More roundabout than the current paradigm of duplicate Linux stacks and supporting services for DevOps just to get stuff deployed? That doesn't make sense to me. Your argument is actually "It seems very new. Not enough people know/use it. Therefore, I won't use it." -- which is fine, but please don't mischaracterise it in terms of increased complexity or expense.

My argument is that you'll need better developers who cost more money. Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug. and you've also got the added overhead of running xen. all in all it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms, since you g…

> My argument is that you'll need better developers who cost more money.

Frankly I wouldn't want a developer who's too dumb to learn OCaml anywhere near my production code. Is this thing new? Yes. Will developers take time (=your money) to get up to speed on it? Yes. But do you need "better" developers, long-term? I don't think so.

> Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug.

Maybe a valid concern, but I remember very similar arguments from C++ programmers in the early days of the JVM. Turns out the JVM is rock-solid and nowadays has better debugging tools than those for C++. There's no reason that couldn't be true for this approach. Or if it's easy to make a multi-target project that builds both a linux binary and a unikernel image, then debugging would be no harder than it is for existing OCaml code.

> and you've also got the added overhead of running xen.

If you're already running linux-in-xen then this is reducing overhead. Even if you're not, it could still improve overall performance by reducing context switching, in the same way as user-mode networking stacks.

> it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms

This sounds rather like "this can't be a good idea because if it was we'd have it already". It's only in the last few years that xen and the "cloud" approach have become so popular, so a lot of new ideas and approaches are still being found.

Post reply on HN