Aubrey Li wrote: > [snip] >> >> 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) ? >> > >> > >> >> I guess it's ok for cyclics, but on the other hand it only addresses the >> cyclic accounting piece of what you point out is a more generic issue. >> > > I got a chance to attend Beijing OpenSolaris user group meeting the day > before yesterday. I was keeping asked when system is in idle, why the percent > sum of top-wakeups > 100%. Most of attendees are system administrators, > as I expect, they really don't care cyclic events, because they can't > do anything > to reduce it. > > Cyclics is a passive event, firstly apic timer interrupt wakes CPU up, and > then > cyclic expire firing , of course here it's quite possible several > cyclic are being batch > processed, and we encounter what we argue, :-) > > So, the event that really wakes CPU up is timer interrupt, not > cyclics. I agree it's > necessary cyclics should be tracked. But I still suggest powertop doesn't > enable > it by default, an option is my preference.
This patch takes cyclic events out of the default report and adds two options: 1) -c adds cyclics to the report 2) -C adds cyclics and collapses firings with the same expire timestamp. >> [snip] >> >> 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. >> > >> That's sort of what I was thinking as well. >> > Yeah, I'm also aware we are currently missing some events like > cross call, especially mwait doesn't generate interrupt. > It looks like PowerTOP can be improved more further, > That's interesting, isn't it? :-) I'm working on figuring out what other kinds of events are causing wake-ups. Hope to have something for you guys soon. thanks Rafael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5934.export URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080428/82746d6b/attachment.ksh>
