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 <[email protected]> > > >> Subject: [MirageOS-devel] Jitsu v0.2.0 with Irmin, Rumprun support > > >> Date: 17 August 2015 11:02:27 GMT-7 > > >> To: [email protected] > > >> > > >> I've written a blog post with a summary of the features here: > > >> http://www.skjegstad.com/blog/2015/08/17/jitsu-v02/ > > >> The more technical details are in the README: > > >> https://github.com/mirage/jitsu/blob/master/README.md > > > > re: jitsi/README.md > > > > > 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 http://www.rump.jitsu.v0.no 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 http://thread.gmane.org/gmane.comp.emulators.xen.devel/224097 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. -mato
