> Laurent Vivier wrote:
> functionnalities:
>
> > - allow to measure time spent by a CPU in a virtual CPU.
> > - allow to display in /proc/state this value by CPU
> > - allow to display in /proc/<pid>/state this value by process
> > - allow KVM to use these 3 previous functionnalities
> >
>
> So, currently time spent in a kvm guest is accumulated as qemu-kvm
> usertime, right? Given that qemu knows when its running in qemu vs
No, it is accumulated as kvm system time.
> guest context, couldn't it provide the breakdown between user and guest
> time (ditto lguest)?
by doing this at kernel level, we can:
- measure exactly the guest time,
- move this part of system time to user time (as you think it should be
user time),
- have consistency between system, user and guest time,
- report values in /proc/state and /proc/<pid>/state, at system wide level
I'm not sure we can measure the guest time at the qemu user level.
Perhaps Rusty can say what he thinks about this ?
Regards,
Laurent
> by doing this at kernel level, we can:
> - measure exactly the guest time,
> - move this part of system time to user time (as you think it should be
> user time),
> - have consistency between system, user and guest time,
> - report values in /proc/state and /proc/<pid>/state, at system wide level
>
> I'm not sure we can measure the guest time at the qemu user level.
>
> Perhaps Rusty can say what he thinks about this ?
>
Even if we cannot _now_, isn't that an easier, and safer change? (and
I don't think we lose anything by design).
Although I don't know KVM to a that deep level, I think it should be
possible to keep the virtual cpus in different process (or threads),
and take the accounting time from there. Perfectly possible to know
the time we spent running (user time), and the time the hypervisor
spent doing things on our behalf (system time).
$0.02.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
Glauber de Oliveira Costa wrote:
>> by doing this at kernel level, we can:
>> - measure exactly the guest time,
>> - move this part of system time to user time (as you think it should be
>> user time),
>> - have consistency between system, user and guest time,
>> - report values in /proc/state and /proc/<pid>/state, at system wide level
>>
>> I'm not sure we can measure the guest time at the qemu user level.
>>
>> Perhaps Rusty can say what he thinks about this ?
>>
> Even if we cannot _now_, isn't that an easier, and safer change? (and
> I don't think we lose anything by design).
Could you explain ? How should I do this ?
I'm _sure_ it is not easier to do that at qemu level.
I don't like to patch kernel (it is the last thing I do to solve a problem: I
know there is always at least one guy to not agree the patch :-P ) but in this
case I think this is the best way to do that.
I think the virtualization notion should be introduced at the kernel level, at
least in the kernel statistics: it is generic, it can be used by other
virtualization tools. As I said, until know CPUs have got only two states
reflected in statistics by "user time" and "system time". Since recently, they
have introduced a third state, the virtual CPU, that, in my opinion, should be
also reflected in the CPU statistics as the "guest time".
>
> Although I don't know KVM to a that deep level, I think it should be
> possible to keep the virtual cpus in different process (or threads),
> and take the accounting time from there. Perfectly possible to know
> the time we spent running (user time), and the time the hypervisor
> spent doing things on our behalf (system time).
But we have always user time accounted as system time. CPU stats are wrong if we
do not modify the kernel. Can you live with wrong statistics ? (yes, I think,
you can, but perhaps someone else not)
Laurent
--
------------- [email protected] --------------
"Software is hard" - Donald Knuth
Am Montag, 20. August 2007 schrieb Glauber de Oliveira Costa:
> Although I don't know KVM to a that deep level, I think it should be
> possible to keep the virtual cpus in different process (or threads),
> and take the accounting time from there. Perfectly possible to know
> the time we spent running (user time), and the time the hypervisor
> spent doing things on our behalf (system time).
I disagree here. First thing, you dont want to have the virtual cpu in a
different process than the hypervisor control code for that cpu. Otherwise
communication has to be made via IPC.
Secondly, Its not qemu/kvm that does the accouting. Its existing userspace
code like top/snmp agents and clients! etc. that would require additional
knowledge which thread is guest code.
I personally like the approach Laurent has taken. Maybe it needs some polish
and maybe we want an account_guest_time function, but in general I think he
is doing the right thing.
Christian
On 8/21/07, Laurent Vivier <[email protected]> wrote:
> Glauber de Oliveira Costa wrote:
> >> by doing this at kernel level, we can:
> >> - measure exactly the guest time,
> >> - move this part of system time to user time (as you think it should be
> >> user time),
> >> - have consistency between system, user and guest time,
> >> - report values in /proc/state and /proc/<pid>/state, at system wide level
> >>
> >> I'm not sure we can measure the guest time at the qemu user level.
> >>
> >> Perhaps Rusty can say what he thinks about this ?
> >>
> > Even if we cannot _now_, isn't that an easier, and safer change? (and
> > I don't think we lose anything by design).
>
> Could you explain ? How should I do this ?
> I'm _sure_ it is not easier to do that at qemu level.
>
> I don't like to patch kernel (it is the last thing I do to solve a problem: I
> know there is always at least one guy to not agree the patch :-P ) but in this
> case I think this is the best way to do that.
>
> I think the virtualization notion should be introduced at the kernel level, at
> least in the kernel statistics: it is generic, it can be used by other
> virtualization tools. As I said, until know CPUs have got only two states
> reflected in statistics by "user time" and "system time". Since recently, they
> have introduced a third state, the virtual CPU, that, in my opinion, should be
> also reflected in the CPU statistics as the "guest time".
After a second thought on this, you seem to be right.
> >
> > Although I don't know KVM to a that deep level, I think it should be
> > possible to keep the virtual cpus in different process (or threads),
> > and take the accounting time from there. Perfectly possible to know
> > the time we spent running (user time), and the time the hypervisor
> > spent doing things on our behalf (system time).
>
> But we have always user time accounted as system time. CPU stats are wrong if we
> do not modify the kernel. Can you live with wrong statistics ? (yes, I think,
> you can, but perhaps someone else not)
>
No, I can't. Just because I suggested an alternate way (even if it was
wrong), it does not mean I want things to be done wrongly.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
On 8/21/07, Christian Borntraeger <[email protected]> wrote:
> Am Montag, 20. August 2007 schrieb Glauber de Oliveira Costa:
> > Although I don't know KVM to a that deep level, I think it should be
> > possible to keep the virtual cpus in different process (or threads),
> > and take the accounting time from there. Perfectly possible to know
> > the time we spent running (user time), and the time the hypervisor
> > spent doing things on our behalf (system time).
>
> I disagree here. First thing, you dont want to have the virtual cpu in a
> different process than the hypervisor control code for that cpu. Otherwise
> communication has to be made via IPC.
> Secondly, Its not qemu/kvm that does the accouting. Its existing userspace
> code like top/snmp agents and clients! etc. that would require additional
> knowledge which thread is guest code.
Yes, the second argument kills me, and I think it leaves no further
room from discussion in my side. Thanks for the enlightenment.
> I personally like the approach Laurent has taken. Maybe it needs some polish
> and maybe we want an account_guest_time function, but in general I think he
> is doing the right thing.
>
Now, me too.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."