On Fri, Mar 02, 2018 at 11:18:10AM +0100, Rafael J. Wysocki wrote:And which is why I said that IMO it would be better to change the current situation.
On Fri, Mar 2, 2018 at 10:41 AM, Du, Changbin <changbin.du@xxxxxxxxx> wrote:The current situtation is that 'state' can be negative for event cpu_idle :(. This
You are right, 'state' not 'cpuid', sorry.This patch only changed 'state' field but cpuid. For cpu_idle event, 'state' isSorry, I'm not sure what you mean.That rather isn't the case if negative values are ever passed to theyes.
tracepoint, right?
Which seems to be the reason why you want to make this change, isn't it?yes, to improve readability.
So maybe fix the code using the tracepoint(s) to avoid passingFor cpu_idle event, [0, CPUIDLE_STATE_MAX) are used to index the idle state arrary,
negative values to it(them)?
so I think a appropriate value for PWR_EVENT_EXIT is -1 (defined in include/trace/events/power.h).
Or do you have a better idea? Thanks!
I'm saying that the code using the CPU PM tracepoints is not expected
to pass -1 as the CPU number to them. IOW, neither -1 nor its UL
representation should ever appear in the output of these tracepoints.
If that happens, it is a problem with the code using the tracepoints
which needs to be fixed. Users should not see any of these values.
singned value, but for cpu_frequency it is unsinged.
The cpuid is always unsinged value. So no one passes -1 as CPU number.
Negative 'state' should not be passed to these tracepoints too, though.
is why I made this change.