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

Meet LKL: Turn Linux Kernel into a Library

lwn.net

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Meet LKL: Turn Linux Kernel into a Library

#11

Post by dohqu8Zi »

bmuk wrote: post #10
dohqu8Zi wrote: post #8

Earlier quoted context omitted.

This does not make any sense. As soon you issue any system call you will trigger a context switch. So, eve without using FUSE and just using LKL as tool to extract your favorite filesystem it will face them. But the context switches not the bottleneck in FUSE. Did you benchmark?

You're absolutely correct; I'm not sure why I was thinking this would eliminate context switching. I don't have a filesystem written, just a lot of musing and reading about it. Wouldn't context switching be the bottleneck when you have lots of small files/transactions? What is usually the bottleneck with FUSE in your experience?

Depends on the FUSE filesystem, but most of the time it is the kerneluser copy process.

Re: Meet LKL: Turn Linux Kernel into a Library

#12

Post by anttiok »

cm3 wrote: post #2

So basically this is Linux's version of NetBSD's Rump, right?

If it's not an instance of a selection of components running on top of externally scheduled threads, it's not a rump kernel in my book. So, strictly speaking no, but the answer really depends on what you want to convey by "basically". Many of the use cases should fit both projects.

Re: Meet LKL: Turn Linux Kernel into a Library

#13

Post by ambrice »

rwmj wrote: post #3

I added experimental support for LKL to libguestfs[1]. It's not upstream in libguestfs because LKL isn't upstream in the kernel, but I'm rooting for it because it'll be nice to have a rump kernel based on Linux. It makes it a much easier sell for all the companies currently built around the "Linux ecosystem". One problem is it appears to require that programs are rewritten, replacing all system calls with lkl_sys_* v…

It might be useful to make an LD_PRELOAD library that does the translation.

Re: Meet LKL: Turn Linux Kernel into a Library

#14

Post by dohqu8Zi »

ambrice wrote: post #13
rwmj wrote: post #3

I added experimental support for LKL to libguestfs[1]. It's not upstream in libguestfs because LKL isn't upstream in the kernel, but I'm rooting for it because it'll be nice to have a rump kernel based on Linux. It makes it a much easier sell for all the companies currently built around the "Linux ecosystem". One problem is it appears to require that programs are rewritten, replacing all system calls with lkl_sys_* v…

It might be useful to make an LD_PRELOAD library that does the translation.

Only in corner cases you want to replace all syscalls to LKL calls. Often you need to call to the host as well. Especially LKL itself needs...

Re: Meet LKL: Turn Linux Kernel into a Library

#15

Post by cm3 »

anttiok wrote: post #12
cm3 wrote: post #2

So basically this is Linux's version of NetBSD's Rump, right?

If it's not an instance of a selection of components running on top of externally scheduled threads, it's not a rump kernel in my book. So, strictly speaking no, but the answer really depends on what you want to convey by "basically". Many of the use cases should fit both projects.

I don't know enough about rump to talk more definitively, and in fact I've failed to find an overview about what it is technically, how it works on NetBSD, how it works outside NetBSD, etc. Does running rump on Linux provide the SMP scalability improvements one misses with NetBSD's kernel for instance? Can you point me at something to read that's short enough to digest in an hour?

Re: Meet LKL: Turn Linux Kernel into a Library

#16

Post by anttiok »

cm3 wrote: post #15
anttiok wrote: post #12

Earlier quoted context omitted.

If it's not an instance of a selection of components running on top of externally scheduled threads, it's not a rump kernel in my book. So, strictly speaking no, but the answer really depends on what you want to convey by "basically". Many of the use cases should fit both projects.

I don't know enough about rump to talk more definitively, and in fact I've failed to find an overview about what it is technically, how it works on NetBSD, how it works outside NetBSD, etc. Does running rump on Linux provide the SMP scalability improvements one misses with NetBSD's kernel for instance? Can you point me at something to read that's short enough to digest in an hour?

Follow the "Getting Started" link on rumpkernel.org. That page includes both short and long reading (should you get more interested ;), and also some "hands on" tutorials should you learn about things better that way (I know I do).

SMP scalability is all about bottlenecks. If the driver is the bottleneck, it won't scale no matter where you run it.

Re: Meet LKL: Turn Linux Kernel into a Library

#18

Post by ycmbntrthrwaway »

So, compared to LibOS, it does not emulate timers etc., but provides host system timers, right? There is no way it will replace LibOS in NS-3 DCE [1] and LibOS will continue to be developed out-of-tree, or is it possible that LKL will be ported to NS-3 as an underlying platform just like it supports POSIX and Windows now?

[1] https://www.nsnam.org/overview/projects/direct-code-executio...

Re: Meet LKL: Turn Linux Kernel into a Library

#19

Post by thehajime »

anttiok wrote: post #12
cm3 wrote: post #2

So basically this is Linux's version of NetBSD's Rump, right?

If it's not an instance of a selection of components running on top of externally scheduled threads, it's not a rump kernel in my book. So, strictly speaking no, but the answer really depends on what you want to convey by "basically". Many of the use cases should fit both projects.

I've been working (though it's too slow) on making answer to this question "yes".

https://github.com/thehajime/blog/issues/1

Re: Meet LKL: Turn Linux Kernel into a Library

#20

Post by thehajime »

ambrice wrote: post #13
rwmj wrote: post #3

I added experimental support for LKL to libguestfs[1]. It's not upstream in libguestfs because LKL isn't upstream in the kernel, but I'm rooting for it because it'll be nice to have a rump kernel based on Linux. It makes it a much easier sell for all the companies currently built around the "Linux ecosystem". One problem is it appears to require that programs are rewritten, replacing all system calls with lkl_sys_* v…

It might be useful to make an LD_PRELOAD library that does the translation.

lkl (and rump hijack library) already do the job, though it's not perfect (at least in lkl right now).
Post reply on HN