RE: [RFC] timer_interrupt: Avoid device timeouts by freezing time if system froze

From: Tian, Kevin <kevin.tian_at_intel.com>
Date: 2005-09-13 02:27:25
>From: Luck, Tony
>Sent: 2005910 6:36
>
>>I am aware of at least two ia64 virtualization systems
>>that rely on the existing behavior to compensate for
>>the fact that one guest linux may be inactive while another
>>is active.  This isn't to say that another solution
>>couldn't be found, but just turning off the existing
>>behavior doesn't seem like a good alternative.
>
>There must be some minimum frequency at which a hypervisor
>allows a guest to run in order for it to operate normally
>[e.g. a guest that gets no cpu time for several seconds at
>a stretch will experience network time-outs with external
>systems that it is unable to supply with "keep-alive" packets].
>
>I'm not sure what that minimum frequency is, but I expect that
>it may be contrained by some of the shorter TCP timeouts.  I
>think that there is one around the 200 milli-second mark.

Yes, this is one important facet in virtualization system. In one of our time virtualization approaches, we add max_jump for max suspension period when one guest is scheduled off. Once the guest is back alive, check is made upon max_jump whether exceeds. If exceeds, it means that we can't show a virtual itc to guest with actual drift which may make device request timeout. Instead we record the actual drift in another field, and only show guest with a max_jump increment on virtual itc. Next time the cached drift value will be checked again, and compensate virtual itc gradually. Max_jump is set as 500ms by default, which is tunable as Tony's example here.

Thanks,
Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Sep 13 02:28:19 2005

This archive was generated by hypermail 2.1.8 : 2005-09-13 02:28:26 EST