Re: [PATCH v2 21/23] sched: psi: implement bpf_psi_create_trigger() kfunc

[Roman Gushchin <roman.gushchin@linux.dev>]

hui.zhu@linux.dev writes:

> 2025年10月28日 07:22, "Roman Gushchin" <roman.gushchin@linux.dev
> mailto:roman.gushchin@linux.dev?to=%22Roman%20Gushchin%22%20%3Croman.gushchin%40linux.dev%3E
>> 写到:
>
>
>> 
>> Implement a new bpf_psi_create_trigger() BPF kfunc, which allows
>> to create new PSI triggers and attach them to cgroups or be
>> system-wide.
>> 
>> Created triggers will exist until the struct ops is loaded and
>> if they are attached to a cgroup until the cgroup exists.
>> 
>> Due to a limitation of 5 arguments, the resource type and the "full"
>> bit are squeezed into a single u32.
>> 
>> Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
>
> Hi Roman,
>
> I wrote an eBPF program attempting to use bpf_psi struct ops and
> bpf_psi_create_trigger to continuously receive memory-related PSI
> events, but I only received one event.
>
> Looking at the code implementation, when an event occurs:
> if (cmpxchg(&t->event, 0, 1) == 0) {
>
> However, in eBPF there appears to be no way to call the equivalent
> of this code from psi_trigger_poll:
> if (cmpxchg(&t->event, 1, 0) == 1)
> to reset the event back to 0.
>
> Would it be possible to add an additional BPF helper function to
> handle this? Without a way to acknowledge/reset the event flag,
> the trigger only fires once and cannot be reused for continuous
> monitoring.

Hi Hui,

Good point. I'll add something in v3, which I'm working on, if I'm going
to preserve the bpf psi infrastructure in the current form. An
alternative approach suggested by Tejun was to use a simple tracepoint
and implement the rest in BPF - something I'm exploring right now.

Thanks!