Eric Saxe wrote: > Rafael Vanoni wrote: >> It depends. For instance, writing a lot to disk shows a lower wakeup >> count than events: >> >> Wakeups-from-idle per second: 1566.7 interval: 2.0s >> no ACPI power usage estimate available >> >> Top causes for wakeups: >> 88.4% (1384.6) <interrupt> : pci-ide#0 >> 9.5% (149.3) <kernel> : uhci`uhci_handle_root_hub_status_change >> 7.7% (120.4) <interrupt> : nvidia#0 >> 4.4% ( 68.2) java : <scheduled timeout expiration> >> 4.3% ( 66.7) <kernel> : ehci`ehci_handle_root_hub_status_change >> 4.3% ( 66.7) <kernel> : genunix`clock >> 2.1% ( 33.3) <kernel> : genunix`cyclic_timer >> 0.9% ( 13.9) <kernel> : genunix`lwp_timer_timeout >> > Right, because there's a DTrace probe that's firing when we get an > interrupt for the pci-ide#0 device...but that doesn't necessarily result > in an idle CPU waking up. :) It's a similar issue to the cyclics being > batched processed.
Yep :) So do you think the solution to batch processing is a good one (reporting one event per expire timestamp) ? >> While sitting idle shows a higher wakeup count: >> >> Wakeups-from-idle per second: 562.7 interval: 2.0s >> no ACPI power usage estimate available >> >> Top causes for wakeups: >> 26.5% (149.3) <kernel> : uhci`uhci_handle_root_hub_status_change >> 21.5% (120.9) <interrupt> : nvidia#0 >> 12.2% ( 68.7) java : <scheduled timeout expiration> >> 11.8% ( 66.7) <kernel> : ehci`ehci_handle_root_hub_status_change >> 10.3% ( 57.7) <kernel> : genunix`cyclic_timer >> 7.5% ( 42.3) <kernel> : genunix`clock >> 2.7% ( 15.4) thunderbird-bin : <scheduled timeout expiration> >> 2.4% ( 13.4) <kernel> : genunix`lwp_timer_timeout >> > This makes me wonder if there's a way that we could dig around to see, > when the idle-state-transition probe fires (because we're coming out of > halt/mwait/etc), to see what's waking us up (rather then trying to > correlate wakeups with events elsewhere in the system). > > It's probably a short list...either: > - Device interrupt > - cyclic apic timer related firing > - cross call (poke) from another CPU because something became runnable > > If we can figure out which of the above things is responsible for the > idle-state-transition, and can then get information about the thing that > happened: > - Which device > - which cyclic is due > - what became runnable > > ...and then have powertop report that...that should get us pretty close, > I would think. > What do you think? Sounds good. Not sure if it's possible since the idle-state probe doesn't tell us much, but I'm gonna have a look around. Maybe one way would be to have a script that ties every event to a firing of idle-state. I got a couple of ideas on how to report it, visually-wise. Should be fun. thanks Rafael
