Hi Aubrey Sorry for the late reply, I got caught up into another project. I'll work on your suggestions and have something for you next week. I'm going away for an OSS conference this week.
thanks Rafael Aubrey Li wrote: > 2008/4/8 Rafael Vanoni <Rafael.Vanoni at sun.com>: >> - added the -i option, which implements what we've been talking about >> correlating cyclic events with idle state transitions >> > That's not what I expect. > 1) the bug is not fixed in the default output. > 2) output with -i option on my side, clock/cyclic wakeup is missing. > and -i option is useless by the common user. > ======== > Wakeups-from-idle per second: 337.0 interval: 8.0s > > Top causes for wakeups: > 44.6% (150.4) <kernel> : > uhci`uhci_handle_root_hub_status_change > 19.8% ( 66.6) <kernel> : > ehci`ehci_handle_root_hub_status_change > 10.0% ( 33.8) java : <scheduled timeout expiration> > 3.0% ( 10.0) <kernel> : ata`ghd_timeout > 1.8% ( 6.0) <kernel> : uhci`uhci_cmd_timeout_hdlr > 1.2% ( 4.0) <kernel> : genunix`schedpaging > 0.9% ( 3.0) <kernel> : genunix`lwp_timer_timeout > 0.8% ( 2.7) <interrupt> : e1000g#1 > 0.8% ( 2.6) sched : <scheduled timeout expiration> > 0.3% ( 1.0) <kernel> : TS`ts_update > 0.3% ( 1.0) <kernel> : e1000g`e1000g_local_timer > ----snip---- > ======== > > as we discussed before, the root cause is, cyclics are being batch processed. > so one wakeup has 3 or more cyclics. that causes the count of > "software waking up" > doesn't match the counts of the "cpu wakeups", and because these > cyclics number is > too large, always be equal to the clock frequency, it looks very > remarkable and confusing. > > Maybe we should deal with this issue by this way: > > (1) from the system admin's point of view, cyclics reports is > meaningless, even if they > found inefficient cyclic subsystem consumers, they can't do anything > but just feel frustrated. > However, back to back applications is different, they can be killed by admin. > > (2) from the developer's point of view, cyclics report is necessary, > tracking down the > inefficient consumers will improve the solaris kernel. > > So I suggest we make (1) as default and add an option to enable (2) or > more events. > > Does this make sense? > > Thanks, > -Aubrey
