On Thu, 2026-06-11 at 12:30 +0200, Valentin Schneider wrote: > On 11/06/26 10:59, Tomas Glozar wrote: > > [just replying to comments, will do a full review later] > > > > st 10. 6. 2026 v 21:51 odesÃlatel Crystal Wood <[email protected]> napsal: > > > > > > On Wed, 2026-06-10 at 15:04 +0200, Valentin Schneider wrote: > > > > Osnoise already implictly accounts IPIs via its IRQ tracking, > > > > > > Does it? It seems that IPIs bypass the kernel/irq subsystem on some > > > arches (including x86, but not ARM). > > > > > > It would be nice to solve this properly by adding generic ipi > > > entry/exit tracing (similar to what ARM already has). > > > > > > > Isn't that precisely what the ipi tracepoints used by this > > implementation (ipi:ipi_send_cpu) are for? > > > > Well, these catch the emission of the IPI, which is great for investigation > - slap a stacktrace trigger and you (most of the time) get the source of > your interference. > > However Crystal's point is that on x86 (and I assume other archs) receiving > & handling these IPIs is "special" and doesn't go through the generic irq > subsystem and thus has to be tracked separately, which is why osnoise has > this fairly lengthy osnoise_arch_register() thing.
Oh, I missed the arch hook. I feel better now :-) (I'd feel better if it didn't rely on osnoise-specific arch code being updated to match if some new interrupt path pops up, but oh well.) > > > > > > Alternatively I can have this be purely supported in userspace osnoise > > > > by > > > > hooking into the IPI events and counting IPIs separately from the > > > > osnoise > > > > events. > > > > > > One benefit I could see of doing this in kernel osnoise would be if you > > > could atomically correlate the count with the particular noise > > > interval, but this patch doesn't do that. > > > > > > > The count is already reported by cycle on the kernel side in the > > patchset, right? It's only missing in the current RTLA (userspace) > > part, as there is no statistic using the information. But it can still > > be collected through custom histogram triggers. Not sure I follow... this patchset reports a count of IPIs, not cycle info, but the count is based on when the IPIs were sent, not received. The IPI send events capture cycle info, but that's not what this patchset adds. I'm not sure that it really matters though. I had been thinking of this more like the interference count, which is atomic with respect to a single noise (and thus the sender of the noise would be outside that window). But this count is reported over the entire osnoise sample period, so a little slop is probably OK. -Crystal >
