Re: kvm guest loops_per_jiffy miscalibration under host load

Glauber Costa
2008-07-07T19:32:27Z

On Mon, Jul 7, 2008 at 4:21 PM, Anthony Liguori <aliguori@us.ibm.com> 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."