>>>> 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: > > > ~3k xcalls generated by PowerTOP. But if you turn the c-state > report off:
> 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 ? I understand this and I think it's expected. my concern is, events report calculation depends on the C-state transition number, when you turn c-state dtrace probe off, this number becomes obsolete for the next loop. And I don't think it's fixed in your updated webrev. > >> 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. This depends on the quality of 7953, and we already seem to have the different opinion, :) > >> 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, -Aubrey
