Rafael Vanoni wrote: > Eric Saxe wrote: >>> [snip] >>> The problem is somewhat obvious. There's no guarantee that the next >>> thread is the actual offender. It's very likely, but not guaranteed :( >>> >>> Any thoughts? >>> >> I think the apprach is probably ok. Like you said, the trick is to >> figure out what's causing the idle-state transition...and before I >> think we figured either: >> 1 device interrupt >> 2 "poke" because something became runnable on the local queue >> 3 "poke" because something became runnable on a remote queue that >> was already busy >> 4 xcall for some other reason >> >> - You might want to use the "sched::on-cpu" probe to catch the first >> thread that this CPU is now going to run (what if the next thread is >> a kernel service thread)? If that's the next probe to fire, it's >> probably scenario 2. >> - If the sched::dequeue probe fires before sched::on-cpu, it's >> probably scenario 3. >> - If an interrupt probe fires before the idle-state transition probe >> (which will happen since the CPU will awake to the interrupt >> handler), then it's probbaly scenario 1. >> >> Then I would be curious how much is left...which I assume would fall >> into the scenario 4 bucket. :) > > I think I may have found a better alternative. Instead of chasing the > threads around, we could check the cpu_t->cpu_disp_flags field for the > processor state and only report the events that happen when a cpu is > idle. > > Here's the default event.c script with those changes. The values are > close to the number of calls to i86_mwait, so it seems to be working. > > What do you think ? It's a good apprach, i'm a bit worried that the script would know a bit too much about the kernel implementation (function names, etc) so I'm wondering if we can get this sort of observability without relying on fbt probes (that may go away or break if the function name or signature changes). Very cool that it seems to be more accurate...
-Eric
