151–160 of 192 posts
Earlier quoted context omitted.
Out of the loop, why is Linux now "more hybrid"?
Because it has a crap ton of drivers and shit in the kernel, which is the opposite of unikernel/microkernel approach where most of this functionality is implemented in userspace. See eg Minix
Brendan has a lot of great content that gets posted here regularly: http://www.brendangregg.com/ (I'm still trying find the time to get through it though). There's also https://github.com/iovisor/bcc#tools as an easy way to get started using BPF.
He also has a book coming out this month, BPF Performance Tools http://www.brendangregg.com/bpf-performance-tools-book.html
Earlier quoted context omitted.
I can't find the LKML thread, but there is some fundamental problem with unloading modules safely. BPF programs might not have such limitations.
Oh, neat! Yeah, I didn't think of this but that totally makes sense. BPF programs declare their resources to the kernel (maps, etc.), but modules are reliant on the __exit function cleaning everything up properly. The correctness of __exit is unverified, difficult, and practically one of the least tested pathways which makes it traditionally fraught with bugs.
eBPF can be viewed as a mechanism to safely run user code in kernel since it uses a DSL and a compiler before the byte code is executed in kernel. This opens up doors for running performance critical functionality in kernel without having to bundle it with the kernel or very tightly coupled with the kernel version. Optimizing FUSE is an example: https://extfuse.github.io/ I expect custom security auditing software, r…
I was thinking about something similar to extfuse, but for a remote filesystem. Here's some note scraps: > Server abilities can be changed by uploading JS functions/libs.. > Want to search a file formats meta-data on the server? Upload JS to read the meta-data and index it, and provide the search options.. > Servers should also use the best options for the tasks they provide: Grep to seach text -- and not Grep like f…
Kind of like current serverless tech but instead of running at the edge, you run on the storage node.
EDIT: removed statement about network speed vs ssd speed. Pretty sure I was way off.
I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful. I have a sense it allows much better performance for horizontal scaling, but I'm not sure...
Real-time, low latency, network-based applications. At the pace of network events, CPU is still very fast by perhaps at least order of magnitude. However, latency introduced by system calls is significant. This allows you to run certain classes of application in kernel space with these overheads largely mitigated. Principally it's monitoring and "observability" applications, but apparently it's much more flexible now…
io_uring was introduced to attack this too and essentially is an async, queue-based, batched syscall interface eliminating a lot of that latency overhead. With polling mode you only have to do a syscall when both the application and the kernel are out of work.
Earlier quoted context omitted.
Oh, neat! Yeah, I didn't think of this but that totally makes sense. BPF programs declare their resources to the kernel (maps, etc.), but modules are reliant on the __exit function cleaning everything up properly. The correctness of __exit is unverified, difficult, and practically one of the least tested pathways which makes it traditionally fraught with bugs.
A BPF->kernel module compiler would ensure all necessary cleanup happens in __exit automatically
Doing the verification offline is a non starter. Appending the verification information and reverifying it at load time is more work than a BPF runtime as it is as you have to reproject ISA semantics in a more complex way.
This is less about BPF vs native code, and more about the process model vs the event based model of application programming. Event based handling is inherently more efficient because it runs in the context of the caller, instead of requiring its own context like in process-based applications. This is the main reason why file system code in the kernel is more efficient than file system servers running in a different p…
Earlier quoted context omitted.
According to https://news.ycombinator.com/item?id=18496054 , these programs have to halt? How does this system guarantee that the programs halt? Does this mean eBPF is not Turing complete?
The language itself is Turing complete, but the kernel will refuse to run a program that it cannot prove will halt. There are three categories of programs; programs you can trivially prove will halt, programs you can trivially prove won't halt, and programs where it's difficult or impossible to prove whether or not will halt. The third category is what we call the halting problem. Only the first category will be run…
This should be useful any time you need a high performance, high security way to instrument or extend a C based program during run time! Not just in kernels.