Li, Aubrey wrote: > Rafael.Vanoni at Sun.COM wrote: > >> Li, Aubrey wrote: >>> Rafael.Vanoni wrote: >>> >>>>> These issues are replicable when you keep pressing "I" per ptop >>>>> interval. Actually, when you close the cstate statistics, total >>>>> event number is not valid for the subsequent report, and the whole >>>>> report will be messed up. >>>> Ok, I'll have a look at this tomorrow morning. But the problem is >>>> not persistent, if you wait until all the keystrokes are processed, >>>> the report goes back to normal. Not sure there's a way to avoid >>>> this since it's the delay of stopping and restarting the DTrace >>>> program >>>> every time >>>> you freeze one of the windows. >>>> >>>> Rafael >>> The problem is here, why freezing windows need to stop dtrace? >>> When you stop cstate dtrace probe, the total event number is not >>> valid any longer, the subsequent report will be broken. >>> >>> Just want to know, for what reason is this feature requested? >>> >>> -Aubrey >> My motivation was/is to allow the user to lower the side effects of >> having three DTrace programs running at the same time, while >> still being >> able to use some of the information ptop provides. So we need to stop >> the scripts, and not just freeze the display. >> >> I've also been able to identify the c-state program as responsible for >> the vast majority of the xcalls we see on mid-large systems, and I've >> been trying to tune our DTrace parameters around it. >> >> What do you think ? >> >> Thanks, >> Rafael > > Your answer didn't address the problem above. When stop the cstate dtrace > probe, the total event number is not valid any longer, the subsequent report > is broken. > > And, for what reason we need to lower the side effects? When we are monitoring > the system, the impact was expected.
On a dual socket, quad core Nehalem box: -- Wakeups-from-idle per second: 3545.9 interval: 5.0s no ACPI power usage estimate available Top causes for wakeups: 91.4% (3242.1) sched : <xcalls> unix`dtrace_xcall_func 2.8% (100.0) <kernel> : genunix`clock 2.2% ( 77.4) <kernel> : genunix`cv_wakeup 0.8% ( 29.1) sched : <xcalls> unix`hati_demap_func -- ~3k xcalls generated by PowerTOP. But if you turn the c-state report off: -- Wakeups-from-idle per second: 335.0 interval: 5.0s no ACPI power usage estimate available Top causes for wakeups: 29.9% (100.0) <kernel> : genunix`clock 23.4% ( 78.3) <kernel> : genunix`cv_wakeup 21.4% ( 71.7) sched : <xcalls> unix`dtrace_xcall_func 7.0% ( 23.5) <kernel> : uhci`uhci_handle_root_hub_status_change -- We no longer have the ~3k xcalls, and the number of wakeups is down by that same amount. Is this what you're referring to ? > Actually, I really like to separate this patch into two, and commit 7951 > first. > As for 7953, I think it's a big change for powertop, it would be better to me > to putback after the new version release. Ok, maybe we should ask someone else's opinion on this one, since we can't seem to agree on it :) It will take me more time to split the patch in two than to test and fix whatever bugs we find. > We have several critical bug-fixes in ptop repo. How's the progress to putback > into ON? I think we should prioritize the putback. It's in progress, we just have to stop finding bugs in the fixes. Patches to both p and c-state reports should go into the current build, I'm not waiting for this patch. Thanks, Rafael
