public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <Laurent.Vivier@bull.net>
To: Avi Kivity <avi@qumranet.com>
Cc: Ingo Molnar <mingo@elte.hu>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND 2][PATCH 4/4] Modify KVM to update guest time	accounting.
Date: Mon, 15 Oct 2007 21:45:18 +0200	[thread overview]
Message-ID: <4713C34E.5080607@bull.net> (raw)
In-Reply-To: <47139959.7090900@qumranet.com>

No more comments: I agree.

We can move the "&= ~PF_VCPU" to kvm_guest_exit() and remove it from 
account_system_time(). Moreover it will simplify the code for s390...

Regards,
Laurent

Avi Kivity wrote:
> Laurent Vivier wrote:
>> 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?]
> 
>> 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.
> 
> 
>>  
>>>> 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.
> 


  reply	other threads:[~2007-10-15 19:45 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-10 14:13 [RESEND 2][PATCH 4/4] Modify KVM to update guest time accounting Laurent Vivier
2007-10-15  9:38 ` Ingo Molnar
2007-10-15  9:47   ` Avi Kivity
2007-10-15  9:50     ` Ingo Molnar
2007-10-15  9:51     ` Ingo Molnar
2007-10-15 10:02       ` Avi Kivity
2007-10-15 10:53         ` Laurent Vivier
2007-10-15 11:15           ` Avi Kivity
2007-10-15 11:33             ` Christian Borntraeger
2007-10-15 11:38               ` Laurent Vivier
2007-10-15 14:39                 ` Christian Borntraeger
2007-10-15 14:45                   ` Laurent Vivier
2007-10-15 11:37             ` Laurent Vivier
2007-10-15 12:07               ` Avi Kivity
2007-10-15 12:29                 ` Laurent Vivier
2007-10-15 16:46                   ` Avi Kivity
2007-10-15 19:45                     ` Laurent Vivier [this message]
2007-10-17 13:08                   ` [PATCH] clear PF_VCPU in kvm_guest_exit() Laurent Vivier
2007-10-17 13:18                     ` Christian Borntraeger
2007-10-17 14:16                     ` Avi Kivity
2007-10-17 15:09                       ` Laurent Vivier
2007-10-18 12:39                     ` Use virtual cpu accounting if available for guest times Christian Borntraeger
2007-10-18 12:41                       ` Avi Kivity
2007-10-19 16:57                       ` [kvm-devel] " Hollis Blanchard
2007-10-19 17:18                         ` Hollis Blanchard
2007-10-18 13:19                   ` [PATCH] move kvm_guest_exit() after local_irq_enable() Laurent Vivier
2007-10-18 13:32                     ` [kvm-devel] " Avi Kivity
2007-10-18 13:49                       ` Laurent Vivier
2007-10-22  8:26                     ` Ingo Molnar
2007-10-22  8:51                       ` Avi Kivity
2007-10-22  8:57                         ` Ingo Molnar
2007-10-22  9:10                           ` [kvm-devel] " Avi Kivity
2007-10-15 11:19           ` [RESEND 2][PATCH 4/4] Modify KVM to update guest time accounting Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4713C34E.5080607@bull.net \
    --to=laurent.vivier@bull.net \
    --cc=avi@qumranet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox