This group is locked. No changes can be made to the group while it is locked.
Date 1 - 3 of 3
[Ext] Re: [iovisor-dev] Questions about current eBPF usages
Thanks a lot, Yonghong. From your response:
In your case, the bpf program is to influence io scheduling decisions.
1. How can I make a kernel function use the return value of a eBPF program/function?
2. An KProbes related question: from an old article https://lwn.net/Articles/132196/ which was written in 2005, it said:
The current KProbes implementation, however, introduces some latency of its own in handling probes. The cause behind this latency is the single kprobe_lock which serializes the execution of probes across all CPUs on a SMP machine.
```I read it as "functions (e.g., eBPF functions) attached to KProbes are executed in serial, i.e., the same eBPF function can not be run by multiple threads at the same time". As eBPF programs frequently use KProbes to hook to kernel functions, do you know if it's true currently that the calling of a eBPF function/program is single-threaded?
On Thu, Oct 15, 2020 at 11:03 PM Jiada Tu <jtu3@...> wrote:
e.g., in kernel/events/core.c, for perf event overflow handler, we have
ret = BPF_PROG_RUN(event->prog, &ctx);
event->orig_overflow_handler(event, data, regs);
The above `ret` is the return value from the bpf program.
The article is 2005, I am not sure whether this serialization of
kprobes across all CPUs still true or not. bpf subsystem won't prevent
from executing on all cpus in parallelism if kprobe subsystem allows
We recently have kfunc based probing, this is trampoline based, much
faster and does not have this restriction.
Thank you very much, Yonghong! Those are very helpful.
|1 - 3 of 3|