Wonder how this differs from exokernals: https://pdos.csail.mit.edu/archive/exo/
Unikernels: The Next Stage of Linux’s Dominance (2019)
151–160 of 187 posts
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#152Earlier quoted context omitted.
I also don't get it. "Linux as a unikernel" does not make sense. The entire point of a unikernel is to not have the OS in every container/VM.
The crucial part of the paper is that they: • Added a new kernel configuration option to allow theuser to select if he/she wants to compile the Linux kernel as UKL. • Added a call to an undefined symbol (protected by an #ifdef) that can be used to invoke application code rather than creating the first userspace process. • Created a small UKL library which has stubs for syscalls. These stubs hide the details of invoki…
Thank you! That great summary should be the top post.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#153Wonder how this differs from exokernals: https://pdos.csail.mit.edu/archive/exo/
Exokernels are orthogonal to unikernels.
Unikernels run exactly one application, but can be based on an arbitrarily complicated OS (specialised) to that one application. Exokernels can run arbitrarily many applications, but OS functionality is minimal and limited to ensuring protection and multiplexing of resources.
Specialising a rich OS (such as Linux) to a single application might yield OS functions that are as restricted as those you find in an exokernel.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#154Seems to me that a unikernel database should be the first application. Databases tend to bypass practically all the facilities of a kernel anyway. It’s often surprised me that they haven’t merged before now.
I think this is the paper https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h.... There's a great summary by cormacrelf below of some of the details. This kind of things comes and goes across the decades. Back in the 90s it was common for databases to implement their own file systems or memory management, but gradually the OSs of the day added features make this unnecessary. As we found then, you lose so much flexibility to modify the os via config changes, adding new monitoring or whatever if you had the db directly connected to the os. I'd hate to give that up for more efficiency. There's a lot of 'strength' in an OS separating various things from the database itself, giving that flexibility.
A modern DB needs efficient interaction with the OS of course, but I'd say based on experience at many companies a bigger challenge than raw efficiency is the ability to implement changes in the db itself. I've worked on 4 or 5 major databases and we can always identify many ways to improve execution, plan selection, various aspects of the db, it's just the giant challenge to alter a big code base that blocks improvements more than OS layers. Improving plan choice can make queries thousands of times faster - but you have to be able to implement it.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#155Earlier quoted context omitted.
The word "latency" covers many things, many subtly different from each other. One of its meanings, unrelated to the one you're talking about, is the delay in signal flow caused by algorithms (many digital filters, for example). Often called "plugin delay compensation", or more generically "latency compensation". Let me just point out that it has taken 20 years and a guy whose PhD thesis was about latency compensation…
The complexity of solving such problems generally is actually what drives me to start from scratch: rather than solve an intractable general problem, instead limit the scope of where the project must run and what it must do. My perception is that I am not capable of reliably tuning a general purpose OS for a total system latency of under 10 msec. I can't give the total system a hard number and believe that it will ob…
You still won't be safe against several/most of the causes outlined in the page from the Ardour manual that I linked to.
SMIs, random hardware that locks the bus for too long ... out of the kernel's control.
If you really want 10msec finger->ear (a goal that I would say is reasonable, though given many live performer's and mixing engineer's normal physical setups, probably excessive) and you want to guarantee it, it's not just the OS but the hardware you'll have to change. You cannot guarantee the required scheduling on general purpose (intel/amd) motherboards unless you take great care with the selection, and even then ... I've heard that financial services/investment firms are the main reason you can still buy mobos without SMIs, because their "latency" requirements would be broken by these interrupts.
On the other hand, the "not-guaranteed" case with a reasonable mobo, sensible bus connected devices, an RT kernel and properly written user space software is going to work almost all of the time. Just no guarantees.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#156> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…
Security (general lack of user-land and in-ability to run more than one program), server density (run thousands of vms/box).
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#157Earlier quoted context omitted.
As for contributing to existing projects, I hear you — I've been highly active in Open Source for well over a decade. Conceptually, the closest thing to what I want to do is Pure Data — and I have in fact contributed to it. But I'm also extremely motivated and willing to go all the way down and write the entire thing from scratch if I have to. Or to learn enough about every last step in the chain that I can actually…
If you want to check, I have a small (and not very good tbh) benchmarking chapter in my thesis where I detail the steps I have followed to get fairly low scheduler tick times of my software - for simple graphs the best I could do was to go to less than 100 microseconds with ~20 microseconds of jitter (p.187) for a tick: https://tel.archives-ouvertes.fr/tel-01947309/document ; also see the intro of section 10.4 with a…
What audio hardware are you using that allows 16 samples per buffer? Must be something ancient, I think?
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#158> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…
Security (general lack of user-land and in-ability to run more than one program), server density (run thousands of vms/box).
That does very little for security, if it's not a net negative at all.
Most attacks aim at executing arbitrary code in the process space of the application being targeted. The lack of user-land does not help.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#159Seems to me that a unikernel database should be the first application. Databases tend to bypass practically all the facilities of a kernel anyway. It’s often surprised me that they haven’t merged before now.
kOS (k language as a standalone OS) was a project but I guess it got canned. Unfortunate, I would love to have tried out a standalone kdb+/q installation.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#160I'm one of the authors on this paper, so ask away if you have questions.
isn't it hard to develop/debug/monitor an application with this approach? I mean you can't just run a debugger as another process and attach to the thing, you can't run tcpdump or strace, nothing of that sort. Also every bad pointer access will require a reboot, wouldn't it? I mean how do you develop an application with this approach?
I guess you would use an emulator to debug. Which seems like good workflow design to me.