Live data from Hacker News

Meet LKL: Turn Linux Kernel into a Library

lwn.net

1–10 of 25 posts

Re: Meet LKL: Turn Linux Kernel into a Library

#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_* variants. For some programs this is necessary, because you want to differentiate between (eg) lkl_sys_open (open a file through LKL) and regular open (open a file on the host), but it's also a pain for any significant program.

[1] https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-b...

Re: Meet LKL: Turn Linux Kernel into a Library

#7
post #5

Does this still incur the penalty of context switching from user space to kernel space? Filesystems are an interest of mine, and this would be a nice alternative to FUSE if it could mitigate the context-switching overhead.

If you use it to write a FUSE filesystem, then yes, because it's using FUSE.

If you link (-llkl) directly to your program, then no, since it's all in the same process. But this is not exposing the POSIX API or a host filesystem, so that's possibly not useful, depending on what you're trying to do.

I compare lkl to libguestfs in my article here: https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-b...

Re: Meet LKL: Turn Linux Kernel into a Library

#8
post #5

Does this still incur the penalty of context switching from user space to kernel space? Filesystems are an interest of mine, and this would be a nice alternative to FUSE if it could mitigate the context-switching overhead.

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?

Re: Meet LKL: Turn Linux Kernel into a Library

#9
post #7
post #5

Does this still incur the penalty of context switching from user space to kernel space? Filesystems are an interest of mine, and this would be a nice alternative to FUSE if it could mitigate the context-switching overhead.

If you use it to write a FUSE filesystem, then yes, because it's using FUSE. If you link (-llkl) directly to your program, then no, since it's all in the same process. But this is not exposing the POSIX API or a host filesystem, so that's possibly not useful, depending on what you're trying to do. I compare lkl to libguestfs in my article here: https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-b...

Ah okay, I think I understand more now. Thanks for the link, I'll check it out!

Basically this is a kernel running in userspace, not hooking into the actual kernel running in kernel space?

Re: Meet LKL: Turn Linux Kernel into a Library

#10
post #8
post #5

Does this still incur the penalty of context switching from user space to kernel space? Filesystems are an interest of mine, and this would be a nice alternative to FUSE if it could mitigate the context-switching overhead.

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?
Post reply on HN