Eric Saxe wrote: > Li, Aubrey wrote: >> err..., firstly, how about the clock CPU or uniprocessor system? >> > Yes, for the clock CPU / uniprocessor system, I wouldn't > expect the gap > to be very long (right now). > >> do you want to calculate the gap or not? >> > My thought is yes...although as you point out in some cases that gap > won't be very large, but looking ahead that might not be the case. > Actually we didn't sync up the Dtrace probe and the beginning sampling time in P-state. It's ok, because we can get residency of every p-state. Similar with P-state, we can't sync up the time between Dtrace probe and sampling for C-state either. But this time is not ok, we can only get the time for C0, we subtract C0 from sampling time to get C1. That's the root cause of the bug: [C-state statistics seem a bit off]. So, cost/function may be a bit high to me.
>> And, for other CPUs, how do you read their kstat from clock CPU? >> > You can read any CPUs kstats from any CPU. The act of reading the CPU > triggers the internal kstat update routine, which reads the state for > the given CPU from someplace where it's been stashed (such as it's CPU > structure). All that can be done without waking the sleeping CPU. > > Thanks, > -Eric Let me have a try first, ;-) Thanks, -Aubrey
