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

BPF: A New Type of Software

brendangregg.com

Post reply on HN
Print view View original

161–170 of 192 posts

Re: BPF: A New Type of Software

#161

Post by jancsika »

PaulDavisThe1st wrote: post #145
MisterTea wrote: post #119

Earlier quoted context omitted.

> So at least in this domain I have a hard time seeing how eBPF could practically help realtime scheduling. Right, because jack is a user space collection of programs. It's obvious that any real-time or low latency DSP audio processing pipeline would have to be moved to BPF in its entirety. So yes, BPF would work just fine if a new DAW pipeline was designed to work with in it. User space programs would only function…

You're never going to fit Ardour's engine into 1M instructions, nor is it going to work without unbounded loops. So that's not going to happen. More interesting would be using BPF for the driver and being able to directly invoke JACK (or some other user-space endpoint) in a way that essentially bypasses the scheduler. Put differently: rather than rely on the normal scheduler pathway to waking up JACK (or some other u…

Does the eBPF program need to communicate with userspace?

For example, can there be an eBPF "hello world" Dalek modulator that just sits between ALSA's audio input and output?

Re: BPF: A New Type of Software

#162

Post by jancsika »

PaulDavisThe1st wrote: post #147
rusk wrote: post #99

Earlier quoted context omitted.

Hm, good point. But couldn't you say the same thing about CUDA? There is an overhead involved in shunting data to and from the cores ... but the nature of the work being done, and the massive parallelism, mean the overall end-to-end volume of throughput increases dramatically. I don't know enough about audio processing to answer your specific question ... but processing network traffic for instance, you have the oppo…

There's bandwidth and there's latency. CUDA has the bandwidth, but not the latency, for generalizable low latency audio processing.

It could still be considered low latency by adding the constraint that all use cases are in the category of call-and-response musical forms. :)

Re: BPF: A New Type of Software

#163

Post by manyworlds »

monocasa wrote: post #157
manyworlds wrote: post #153

Earlier quoted context omitted.

A BPF->kernel module compiler would ensure all necessary cleanup happens in __exit automatically

A BPF to kernel module compiler wouldn't let the kernel verify the program in a real way. There's still work to be done, bit the end goal of BPF is pretty obviously to allow non root users to load programs. 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 com…

Hmm I think bpf today is used in fully trusted environments. Kernel level verification is unnecessary except in untrusted containerized environments or when running untrusted applications, both use cases being relatively rare/specialized.

I think the main benefit of bpf is that it prevents you from shooting yourself in the foot. Running totally untrusted code in the kernel just seems like a recipe for disaster and for that reason it makes sense bpf is still limited to root.

Re: BPF: A New Type of Software

#164

Post by manyworlds »

ClumsyPilot wrote: post #113
TickleSteve wrote: post #53

Earlier quoted context omitted.

A BPF interpreter can literally be ~100 LoC. A WebAssembly VM on the other hand will likely be ~1million LoC (without checking). One is suitable for embedding into a kernel, the other isn't.

Thank you, I appreciate the perspective. Perhaps WebAssembly kernel-space programming would still be viable for major trusted projects, like Kafka, where you literally dedicate the entire machine to that application.

Unikernel or rump kernel would be better for that purpose

Re: BPF: A New Type of Software

#165

Post by monocasa »

manyworlds wrote: post #163
monocasa wrote: post #157

Earlier quoted context omitted.

A BPF to kernel module compiler wouldn't let the kernel verify the program in a real way. There's still work to be done, bit the end goal of BPF is pretty obviously to allow non root users to load programs. 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 com…

Hmm I think bpf today is used in fully trusted environments. Kernel level verification is unnecessary except in untrusted containerized environments or when running untrusted applications, both use cases being relatively rare/specialized. I think the main benefit of bpf is that it prevents you from shooting yourself in the foot. Running totally untrusted code in the kernel just seems like a recipe for disaster and fo…

That's where it is today, but the end goal is removing that restriction. It probably would have happened quicker if Spectre/Meltdown hadn't come out of nowhere. Like it used to be that KVM required CAP_SYS_ADMIN as well, but now that's been opened up to whoever has permissions to the device file. Start requiring "own the box anyway" privileges while the feature bakes, but open it up as it becomes more mature and attackers have a go at it.

It's sort of like how originally you could only jump forward, then the opened it up to any DAG, then they allowed probably bounded loops.

And there's been OSes that don't require root for their in kernel virtual machines, XOK and AEGIS being the prominent examples.

Re: BPF: A New Type of Software

#166

Post by PaulDavisThe1st »

jancsika wrote: post #161
PaulDavisThe1st wrote: post #145

Earlier quoted context omitted.

You're never going to fit Ardour's engine into 1M instructions, nor is it going to work without unbounded loops. So that's not going to happen. More interesting would be using BPF for the driver and being able to directly invoke JACK (or some other user-space endpoint) in a way that essentially bypasses the scheduler. Put differently: rather than rely on the normal scheduler pathway to waking up JACK (or some other u…

Does the eBPF program need to communicate with userspace? For example, can there be an eBPF "hello world" Dalek modulator that just sits between ALSA's audio input and output?

sure there could, but that's utterly unrelated in practical terms to what i think we're discussing, which is ways in which eBPF could impact full-scale audio software rather than limited inline DSP.

Re: BPF: A New Type of Software

#167

Post by manyworlds »

monocasa wrote: post #158
manyworlds wrote: post #72

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…

Sort of, but misses some of the larger picture. The main reason that fs code is faster in the kernel is the direct access to kernel data structures. File system, virtual memory, and buffer cache are all three sides of the same coin. Once you divorce yourself from direct (even if sandboxed) read and writes of the underlying data structures, you impose a massive overhead.

Hmm I don’t think this is the case, at least not when comparing fuse to in-kernel file systems. Having access to native VM structures only helps to the extent that you can avoid copies, yet in fuse, only one extra copy takes place. I think having to switch tasks (and associated work: swapping mm, flushing tlb, ireting/syscalling, synchronization) is really what kills perf

Re: BPF: A New Type of Software

#168

Post by rstuart4133 »

4ad wrote: post #117
throwaway894345 wrote: post #116

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?

Indeed, eBPF is not turing complete.

It's the definition of Turning complete that's the problem. A Turning complete machine must be able to process countably infinite inputs. The halting problem arises from same thing. There is no halting problem if we restrict ourselves to programs that will stop in a bounded time (obviously).

In practice that means a true Turning machine can compute things that aren't actually computable in our Universe, or at least not by the bits of the Universe we understand well. I doubt any engineer will think that "this architecture can't in theory compute things not computable in this Universe" is a strong argument against it.

Re: BPF: A New Type of Software

#169

Post by manyworlds »

monocasa wrote: post #165
manyworlds wrote: post #163

Earlier quoted context omitted.

Hmm I think bpf today is used in fully trusted environments. Kernel level verification is unnecessary except in untrusted containerized environments or when running untrusted applications, both use cases being relatively rare/specialized. I think the main benefit of bpf is that it prevents you from shooting yourself in the foot. Running totally untrusted code in the kernel just seems like a recipe for disaster and fo…

That's where it is today, but the end goal is removing that restriction. It probably would have happened quicker if Spectre/Meltdown hadn't come out of nowhere. Like it used to be that KVM required CAP_SYS_ADMIN as well, but now that's been opened up to whoever has permissions to the device file. Start requiring "own the box anyway" privileges while the feature bakes, but open it up as it becomes more mature and atta…

Sure but I don’t see any compelling use cases to motivate opening it up. Do you have an example of one?

Even if the kernel opens it up without a compelling use case, it seems likely that distribution policy will keep it default locked to root.

Which is my point here. I don’t see a compelling reason to have a JIT in the kernel when AOT BPF seems to cover 90% of all existing use cases. In fact I may even write a bpf to kernel module compiler myself.

Re: BPF: A New Type of Software

#170

Post by simtel20 »

emptysea wrote: post #120
anyzen wrote: post #64

Off topic: this is the same Brendan Gregg of flame charts fame [0][1]. It has solved my skin quite a few times when trying to figure out performance bottlenecks in Python apps (using pyflame[2] to capture data and FlameGraph[1] to convert it to displayable SVG). [0] http://www.brendangregg.com/flamegraphs.html [1] https://github.com/brendangregg/FlameGraph [2] https://github.com/uber-archive/pyflame

Looks like `pyflame` was recently deprecated & archived. I've had success using `py-spy` for debugging perf issues. Flamegraphs are much nicer to work with than cProfile's output. https://github.com/benfred/py-spy

I just wrote up a quick survey of python profilers that hasn't been published yet, and along with py-spy, there is austin (https://github.com/P403n1x87/austin). The thing that I liked the most about austin is that it also samples the memory usage of the system so that you have the context of the world outside of the process being sampled, in case it is useful. That said, py-spy is easier to install (it can be installed via pip).
Post reply on HN