Re: [PATCH v7 00/14] rv: Add task latency over budget RV monitor

[Gabriele Monaco <gmonaco@redhat.com>]

On Tue, 2026-10-20 at 03:18 +0800, Wen Yang wrote:
> 

> > there's been a conversation at the LPC conference about completely migrating
> > RV
> > to BPF.
> > While we aren't sure of its feasibility yet, and it will take time, it's
> > something to keep in mind for new contributions.
> > 
> 
> Understood, and I have been following that direction.  I spent the last
> few days reading the v2 "rv: Add support for BPF monitors" series in
> detail, so the comparison below is against that code rather than the
> general idea.

Great, I'm going to review your series when I get some time.

> > First of all, would dropping RV in-kernel support negatively affect your
> > current
> > workflow?
> > 
> Yes, it would.  Some concrete points, all from the current tree.
> (a) Event ABI.  event_da_monitor / error_env_* in
>      kernel/trace/rv/rv_trace.h are plain tracepoints, so trace-cmd,
>      perf and anything else reading tracefs consume them today with no
>      extra userspace.  The BPF series delivers events through a ring
>      buffer read by the rv tool, so the two backends are not
>      interchangeable for existing consumers.

Good point, you might have noticed a similar discussion is happening also on the
RV-BPF thread. We cannot have the absolute same ABI in BPF, but we probably need
tracepoints or anything that can easily interact with other tracing tools.

> (b) Build and deployment.  On the images we target, BPF is often not
>      compiled in or not permitted:
>        CONFIG_BPF_SYSCALL            default n
>        CONFIG_BPF_EVENTS             needs BPF_SYSCALL
>        CONFIG_DEBUG_INFO_BTF         needed for CO-RE; depends on
>                                      !DEBUG_INFO_REDUCED and pahole
>        LOCKDOWN_BPF_READ_KERNEL      disables the probe_read helpers
>      Those are product constraints, not local build issues.  tracefs/RV
>      works in all of these configurations.
> 
>      There is also a size cost: BPF implies CONFIG_DEBUG_INFO_BTF, and
>      .BTF is resident in RO_DATA and kept in the boot image - about
>      5 MB uncompressed on a full kernel, 1.2-1.6 MB compressed, plus
>      roughly 25% per module with DEBUG_INFO_BTF_MODULES.  On a
>      16-32 MB kernel partition that matters.
> 

I've vaguely heard automotive folks saying they don't want to build BPF support
several times. Finally I get a proper technical reason!

Now I think this isn't easy to sort out, if that's a hard requirement, we are
probably going to need to keep in-kernel monitors around.

> (c) Timing semantics.  tlob arms a per-task hrtimer with
>      HRTIMER_MODE_REL_HARD.  bpf_timer is fixed to
>      HRTIMER_MODE_REL_SOFT and the verifier states "bpf_timer callbacks
>      are never sleepable" .  On PREEMPT_RT the callback runs in a 
> threaded
>      softirq, so the expiry time carries scheduler latency.

I haven't looked into this yet, but from what you say, the bpf_timers code
doesn't really support PREEMPT_RT.

>      For a budget monitor the expiry time is the output, so this is a
>      semantic change, not just overhead.

Well, the expiry time you get from an hrtimer is what you configured + some
system jitter. The jitter here is just going to be less predictable but is it
really the output you need in your monitor?
Or am I missing your point?

> 
>      What a BPF tlob would look like once those exist:
>        - model: still tlob.dot, with rvgen -b extended to the hybrid
>          backend;
>        - state: one record per task in BPF_MAP_TYPE_TASK_STORAGE (or
>          the per-object hash map the series has today), holding the
>          state, the binding id and the budget;

Yeah I wasn't aware of BPF_MAP_TYPE_TASK_STORAGE before, I have a draft V3
(coming some time after the merge window) using that.
But I'd assume this type of storage would simplify the design of your monitor,
which is currently using a PER_OBJ just to add more things to a PER_TASK.
I'm going to keep in mind your use-case where you essentially extend the storage
(which is perfectly fine in BPF since we don't use the task_struct slot).

>        - window: two uprobe programs attached to PATH:START and
>          PATH:STOP, with the binding id and budget passed through the
>          attach cookie or a small config map populated before load;
>        - expiry: a bpf_timer in the same record, armed on state
>          transitions and cancelled on STOP, submitting an error entry
>          to the monitor's ringbuf;
>        - output: the rv tool reads the ringbuf and prints it, and the
>          reactor is linked in with bpf_linker as v2 already does.
> 
>      The DA engine and the ringbuf/reactor plumbing would carry over
>      unchanged.  The three missing pieces are the uprobe
>      attach/configuration path, the timer and env handling in
>      da_monitor_bpf.h, and the hybrid backend in rvgen.
> 
>      None of this argues against migrating.  It argues that the BPF
>      backend has to reach parity on (a)-(c) before the in-kernel path
>      can be removed.
> 


Thanks for taking time to assess this, it looks like the right direction.

Gabriele