hckuo / lupine-linux Goto Github PK

show that the union could feasibly become the new microvm config

So far, we have a discussion on immutable infrastructure and how the dynamic nature of Lupine makes that a bit harder than something like mirage.

The reset of the section needs to be filled out. Here's what we have as notes so far:

Unikernel benefits not covered:

• other language-based anal- yses
• running on a unikernel monitor
• multiple layered implementations of the same abstraction

build time optimization (cross domain)

• compile time (limited for C)
• link time (menuconfig does both compile time and link time)
  e.g., inline crap from the kernel into application code –> can’t do any of it unless application build is also changed –> llvm?

The current boot numbers are not fair between the Linux/firecracker systems and the ukvm/uhyve systems because the latter numbers include teardown time. We should make sure that all are using the same measurement methodology. We have two options:

• make ukvm/uhyve signal when boot happens (like in fc)
• include teardown for firecracker as well

it seems that the first option would be best, as fc will likely have worse teardown than ukvm (and we don't really want to focus on the monitor!)

smp experiments with no-dev vs no-dev-multi

also talk about "graceful degradation of unikernel properties"

We seem to be trying to/on the verge of making a point that the "union config" is in fact better than (or just as good as) having specialization via Kconfig. We need to know how the union config does across all the metrics.

"space/time tradeoffs"
< CONFIG_BASE_FULL=y
< CONFIG_BASE_SMALL=0
< CONFIG_SPARSEMEM_VMEMMAP=y
< CONFIG_TRANSPARENT_HUGEPAGE=y
< CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
< CONFIG_ARCH_RANDOM=y

• lupine-base (lupine-djw-kml)
• lupine-base-nokml (lupine-djw-nokml)
• hermitux is missing
• need lupine-tiny for this

Not sure if we want/need to show both kml and nokml here
Maybe all of the lupine derivitives (e.g., nginx, redis) should show up in the graph as errorbars (e.g., to show max and min)

• lupine-djw-nokml now has paravirt so will be good to see
• lupine-base (lupine-djw-kml) should also be shown
• hermitux is missing

I'm finding it very difficult to know where to start to reproduce the data behind some of the tables and figures.
I expected something like:

• scripts/tables/4_data.sh
• scripts/figures/5_data.sh

etc. etc.

One question we face is "how many popular apps is enough" to make points like "one config is good enough for everything". If we plot a histogram of the number of stars, we can visualize how much popularity we are covering. If we plot it as a CDF, we could make claims like "10 apps cover 80% of the stars on Docker Hub".

Although, idea behind Lupine is to use KML patched kernel, I suspect having nokml kernel for performance comparison would be good. But setting CONFIG_PARAVIRT results in a failed build with the following error message:

arch/x86/kernel/paravirt.c:361:14: error: 'native_load_tls' undeclared here (not in a function)
.load_tls = native_load_tls,

This needs to be fixed in IMO.

Hi,
In the paper there are references to a KML-enabled musl libc. There are also references to it in the code within the repository. Can this modified code or the patch to the library be provided?

Thanks,
Andy

KML kernel on Firecracker fails to start with the following message:

EXT2-fs (vda): error: ext2_lookup: deleted inode referenced: 1228803
cp: can't stat '/trusted/nginx': I/O error

Root cause the is cp command in guest_start.sh where all the respective executables get copied to /trusted

Any idea why we need this? Why not run directly from /usr/sbin?

how do we know app-specific configs are complete
how do we know manual categorization is correct

Is Lupine currently compatible with QEMU/KVM? Current configurations seem to work only on Firecracker.

In limitations section, we should highlight how language-based unikernels like mirage can automatically produce the application manifest

we want to see pthreads vs. green threads

this will look bad, but starts to answer the question "what do you lose when you give up a unikernel design principle", in this case single context

we can put it in context of the tradeoff: unikernels have traded generality, SMP, etc. for this

I'm almost finished writing up the section on specialization through kernel configuration. For the application-specific specialization, I think it would be nice to evaluate what the configuration looks like for different applications (how different it is). The goal would be to see whether one "general" Lupine configuration is good enough, rather than needing to mess with manifests and things like that.

If we had applications that made sense that didn't need a ton of functionality, that would seem the way to argue for specialization, but with the usual suspects (nginx, redis, etc), I expect things are pretty much going to be the same. Probably it would be best to come up with a "representative list", even if that list is things that don't run on the competitors and use that.

In terms of what to measure: 1) total # configuration options, 2) system calls available in the kernel, 3) kernel binary size, ?) anything else??

@hckuo @ricarkol any ideas on what the representative list should be?

(by the way, the representative list can also be used to roughly show how "compatible" other systems really are)

one of unikernel proponents stated advantages has to do with complexity... is this measurable? I would expect things like Hermitux (which is immature and lacks completeness) to look really good in this metric

https://github.com/hckuo/Lupine-Musl-libc

when I try to run build-kernel.sh, It occur an error that repository docker.io/linuxbuild not found: does not exist or no pull access because of Unable to find image 'linuxbuild:latest' locally and Trying to pull repository docker.io/library/linuxbuild.
I also try to pull linuxbuild:latest separately use docker pull linuxbuild:latest, it still occur the error that repository docker.io/linuxbuild not found: does not exist or no pull access.
Is that image was removed from docker hub?

of rump, osv, linux, etc.

is union enough for the new microvm config

relationship between config size and image size (really should be found with make randomconfig)

It seems that Lupine doesn't work with recent Redis releases. The most recent release I managed to run with the currently available configuration is 5.0.4 (using the redis:5.0.4-alpine Docker container image).

Apologies for being obtuse. It is not clear to me which config files in this repo are lupine-base and which are lupine-general (I expect there will be kml/nokml variants)?

see what lupinified app configurations do to boot time