Re: Fwd: [MirageOS-devel] Jitsu v0.2.0 with Irmin, Rumprun support

  • From: Martin Lucina <martin@xxxxxxxxxx>
  • To: Magnus Skjegstad <magnus@xxxxx>
  • Date: Tue, 18 Aug 2015 01:49:21 +0200

On Monday, 17.08.2015 at 23:20, Magnus Skjegstad wrote:

On Mon, 17 Aug 2015, at 22:11, Antti Kantee wrote:
On 17/08/15 18:19, Anil Madhavapeddy wrote:
Begin forwarded message:

From: Magnus Skjegstad <magnus@xxxxx>
Subject: [MirageOS-devel] Jitsu v0.2.0 with Irmin, Rumprun support
Date: 17 August 2015 11:02:27 GMT-7
To: mirageos-devel@xxxxxxxxxxxxxxxxxxxx

I've written a blog post with a summary of the features here:
The more technical details are in the README:

re: jitsi/

Note that rumprun unikernels currently take longer to boot than MirageOS
unikernels. When the disks are mounted as ISO files (as in this example)
the boot time can be more than a second.

The bootstrap time of a rump kernel is in milliseconds (assuming there
are only virtualized devices in the configuration; drivers usually spin
for a while to wait for non-virtualized devices to "settle"). The Xen
infra just takes a long time to spin up to the point where it jumps into
rump kernel bootstrap. However, I thought there were some recent
improvements on this to make Xen spinup comparable to Mirage?

Yes, I'll make that clearer in the README. What I meant to say here was
that it takes a while for Xen to set up the iso files, so the rumprun
kernel will take longer to start from Jitsu. The rumprun unikernel
running at runs with loopback devices
instead and seems to boot faster.

Yes, this is a known problem. The biggest chunk of the startup time is
indeed time taken to spin up QEMU backing the file-backed block devices.

This Xen patch will be in
Xen 4.6 and changes the default behaviour to use loopback devices instead
of QEMU/qdisk. I've back-ported it to Debian Xen 4.4.1 which I run on my
servers and it works fine as long as you remember to up the max_loop
module option.


Other related posts: