On Wed, Jun 10, 2026 at 12:20:19PM -0700, JP Kobryn wrote: > On 6/10/26 11:54 AM, JP Kobryn wrote: > > On 6/9/26 6:21 PM, Shakeel Butt wrote: > >> On Tue, Jun 09, 2026 at 05:16:15PM -0700, JP Kobryn wrote: > >>> On 6/9/26 5:07 PM, JP Kobryn wrote: > >>>> On 6/9/26 12:44 AM, Barry Song wrote: > >>>>> On Tue, Jun 9, 2026 at 12:12 PM JP Kobryn <[email protected]> wrote: > >>>>>>
[...] > >>>>> Do you need tracing on each CPU individually, or is tracing the > >>>>> entire __lru_add_drain_all() invocation sufficient? > >>>> > >>>> I think the latter would be fine. The remote work will invoke the > >>>> mm_lru_add_drain tracepoint, which will show up as kworker stacks. Since > >>>> the event already has the CPU, we could see where queued drains actually > >>>> ran. > >>> > >>> Actually if it's just a single invocation and the only event data is the > >>> force flag, a tracepoint may not even be needed. Other probes can be > >>> installed on function invocation and read the single argument. I can > >>> drop this from v2 and keep the single mm_lru_add_drain tracepoint. > >> > >> No we do want to trace the callers requesting to drain from all the CPUs. > >> If you > >> trace just lru_add_drain_cpu() then you will only see that the drain is > >> requested for a given CPU but no information on the requester. > >> > >> Also as Barry said, I think single trace for whole __lru_add_drain_all() > >> is good > >> enough. > > > > Right, but couldn't that already be done with fentry or kprobe? If we > > only need the calling stack and the argument value of force_all_cpus I > > don't see a strong need for a dedicated tracepoint. > > Nevermind that. I see it's declared inline so I'll add a tracepoint and > send v3. Thanks. BTW even without inline keyword, compiler can still decide to inline a function, so kprobe/fentry are not always reliable. >
