>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 09.02.10 08:55 >>>
>>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>>Attached. After another refinement (in stop_hz_timer()) I didn't see
>>spikes above 1,000 interrupts per CPU per second anymore. But it's
>>still far from being as quiescent as without the patch.
>
>Would you mind elaborating what's refinement and how that may
>reduce spikes? Understand those variants may help draw big picture
>about whole issue.
This was the last hunk in stop_hz_timer() (forcing timeout_abs_ns
to never be in the past relative to the local accumulated time).
>>What's also interesting is that there's an initial period (a 
>>minute or so)
>>where the interrupt rate is really stable (though still not as low as
>>previously), and only then it starts becoming erratic.
>
>What is average interrupt rate for 'stable' and 'erratic' case? Is it
>close to spike (~1000)?
No, during the stable period the rate is less than 50; erratic has
an average rate (not counting the spikes) of about 125.
>BTW, with your current patch there could be still possibility for
>several vCPUs to contend for xtime_lock at same time. Current duty
>vCPU may be preempted in ISR, and then other non-duty vCPU
>will note it not in RUNSTATE_running and then designate itself
>to take new duty. This may not be big issue, compared to original
>always-contending style. But just raise it here and please make
>sure it's actually what's desired by you.
Yes, I realize that. It's a tradeoff (and would probably need further
refinement, if only the whole thing would first work as desired). And
it's getting us back to the fact that pv guests should be allowed to
avoid being preempted for short periods of time.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel