>From: Luck, Tony >Sent: 2005Äê9ÔÂ10ÈÕ 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.htmlReceived on Tue Sep 13 02:28:19 2005
This archive was generated by hypermail 2.1.8 : 2005-09-13 02:28:26 EST