On Mon, Jul 7, 2008 at 4:21 PM, Anthony Liguori <[EMAIL PROTECTED]> wrote: > Marcelo Tosatti wrote: >> >> On Mon, Jul 07, 2008 at 03:27:16PM -0300, Glauber Costa wrote: >> >>>> >>>> I agree. A paravirt solution solves the problem. >>>> >>> >>> Please, look at the patch I've attached. >>> >>> It does __delay with host help. This may have the nice effect of not >>> busy waiting for long-enough delays, and may well. >>> >>> It is _completely_ PoC, just to show the idea. It's ugly, broken, >>> obviously have to go through pv-ops, etc. >>> >>> Also, I intend to add a lpj field in the kvm clock memory area. We >>> could do just this later, do both, etc. >>> >>> If we agree this is a viable solution, I'll start working on a patch >>> >> >> This stops interrupts from being processed during the delay. And also >> there are cases like this recently introduced break: >> >> /* Allow RT tasks to run */ >> preempt_enable(); >> rep_nop(); >> preempt_disable(); >> >> I think it would be better to just pass the lpj value via paravirt and >> let the guest busy-loop as usual. >> > > I agree. VMI and Xen already pass a cpu_khz paravirt value. Something > similar would probably do the trick.
yeah, there is a pv-op for this, so I won't have to mess with the clock interface. I'll draft a patch for it, and sent it. > It may be worthwhile having udelay() or spinlocks call into KVM if they've > been spinning long enough but I think that's a separate discussion. I think it is, but I'd have to back it up with numbers. measurements are on the way. > Regards, > > Anthony Liguori > > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
