Laurent Vivier wrote:
quoted text
> Avi Kivity wrote:
>   
>> Laurent Vivier wrote:
>>
>>  
>>
>>     
>>>> But if we didn't get an interrupt in that time?
>>>>
>>>> We can clear it a bit later, after local_irq_enable() in
>>>> __vcpu_run(). However we need a nop instruction first because "sti"
>>>> keeps interrupts
>>>> disabled for one more instruction.
>>>>     
>>>>         
>>> IMHO, I think it is better to let kvm_guest_exit() empty (you can
>>> remove it, if
>>> you want):
>>>
>>> 1st case:
>>> - unset PF_VCPU in kvm_guest_exit(), all the tick is always for system
>>> time.
>>> Guest time is always 0.
>>>
>>> 1st case and half:
>>>
>>> - like 1st case but we move kvm_guest_exit() as you propose and the
>>> reason of
>>> the interrupt is the tick interrupt. The tick is for guest time only.
>>> I think
>>> the probability is very low.
>>>   
>>>       
>> If the guest is executing for 10% of the time, the probability is
>> exactly 10%, no?
>>     
>
> I think you know that better than me.
>
> But is there homogeneity in probability ?
>   

It's exactly the same issue as with systime and usertime.  The interrupt 
samples the program counter at various points at a fairly low frequency 
(milliseconds) while syscalls last a few dozens of microseconds.  
Probability makes it average out correctly in the end.

[Ingo, what about dyntick?  suppose you have just one process that calls 
read() from /dev/zero repeatedly.  There'd be very few (or no) 
interrupts -- what happens to accounting accuracy?]

quoted text
> I mean, if the guest has a lot I/O, it is interrupted by them and the
> probability to be interrupted by a tick is lower than the time passed in the VCPU ?
>   

Suppose the time to service the I/O is exactly equal to the amount 
running in guest mode.   Then the probability of the interrupt happening 
in guest mode is equal to it happening outside guest mode and you'd get 
50% guest, 50% system/user, which is what you want.


quoted text
>   
>>> 2nd case:
>>> - don't unset PF_VCPU in kvm_guest_exit(), all the tick is for guest
>>> time.
>>>   
>>>       
>> But then even execution in ->handle_exit() is accounted as guest time,
>> which is wrong.
>>     
>
> System time and User time are wrong too as the tick is accounted to the side
> where it appears, even if CPU has executed code from the other side in a
> sub-part of the tick. It's not a good argument.
>   

It's at least consistent... the same errors for everyone, so it averages 
out in the end.

-- 
error compiling committee.c: too many arguments to function

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/