4 ms·

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 alternativ

by bmuk 11y ago

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.

i4k 11y ago
I have the same question.
rwmj 11y ago
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-backend-for-libguestfs/ https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-b...
- bmuk 11y ago
  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?
  - rwmj 11y ago
    Yes, it's the Linux kernel, compiled as a (userspace) library, and linked to applications. The applications use lkl_sys_* functions to call "system calls" in this code-running-as-a-library.
dohqu8Zi 11y ago
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?
- bmuk 11y ago
  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?
  - dohqu8Zi 11y ago
    Depends on the FUSE filesystem, but most of the time it is the kernel<->user copy process.

by bmuk 11y ago

i4k 11y ago

I have the same question.

rwmj 11y ago

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-backend-for-libguestfs/ https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-b...

bmuk 11y ago
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?
- rwmj 11y ago
  Yes, it's the Linux kernel, compiled as a (userspace) library, and linked to applications. The applications use lkl_sys_* functions to call "system calls" in this code-running-as-a-library.

dohqu8Zi 11y ago

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?

bmuk 11y ago
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?
- dohqu8Zi 11y ago
  Depends on the FUSE filesystem, but most of the time it is the kernel<->user copy process.