[Hotplug_sig] Re: [lhcs-devel] Question on /proc/interrupts stats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> When CPU2 is off-lined, the statistics for CPU2 do not 
> appear (expected). However when you look at the before 
> picture (all CPUs present) and after picture (all cpus 
> present after CPU2 re-added), you see that the original 
> data was returned and has incremented:
<snip>
> Results are similar for other interrupt levels.
> 
> This does not seem like the correct approach. Shouldn't an
> added CPU be considered new and stats begin again from zero? 
> 
> Can you please give us guidance on this issue?  Is it
> a bug or expected behavior? 
> 
There are several legitimate options here, including the current behavior.  I'm 
not clear other than kernel developers doing debugging who consumes this data. 
If it is just kernel developers I contend we are capable of understanding 
whatever data is presented.

Current Behavior:
Stats carry over.  The advantage of this is that the stats history is not lost. 
  Consider the scenario where a cpu is moved regularly between two partitions in 
response to workload.  It would probably be best in that situation to keep the 
full history of that cpu during all the times it has been in the partition. 
This view would be consistent with the cpu always being there, just sometimes 
being off.  I haven't fully thought through the impact of a different physical 
cpu being added in the same logical slot, or how virtualized cpus fits into this 
paradigm.  But I suspect they shouldn't change the concept.

Reset every time:
The advantage of this is the cpus start with a clean slate.  There is logic to 
avoiding the situation where some hotplug added cpus have state already and some 
hotplug added cpus start with nothing.  Consistency is not a bad thing.  On the 
other hand this is a bit of selective amnesia, we would be forgetting all past 
statistics only for cpus that had taken some time off.  It's like taking a 
vacation from work and having your old email thrown away while you are gone.

Reset all every time:
It could well be argued that the old cpu statistics from every active cpu serve 
only to confuse things because the cpus were in a different state.  If you 
didn't reset all cpus statistics, then after adding a new cpu you couldn't say 
for instance that cpu 5 is taking 45% of the interrupts.  The statistics are 
meaningless without their context, and by adding a cpu we have destroyed their 
context.  Therefore we should reset all statistics so they all have the same 
frame of reference.  The downside of course is that we lose all history on all cpus.

Personally, I'm fine with the current behavior.  It makes the most sense to me 
and is the least complex to implement (already done).  We maybe should document 
it (send a patch in reply to the one Ashok Raj just posted to lkml).  Unless 
somebody has a real user of cpu statistics that this behavior breaks.

[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux