* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-20 20:34 ` Glauber de Oliveira Costa
0 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-20 20:34 UTC (permalink / raw)
To: laurent.vivier-6ktuUTfB/bM@public.gmane.org
Cc: Jeremy Fitzhardinge, kvm-devel, John Stoffel, linux-kernel,
virtualization
> 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."
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 7:45 ` Laurent Vivier
0 siblings, 0 replies; 17+ messages in thread
From: Laurent Vivier @ 2007-08-21 7:45 UTC (permalink / raw)
To: Glauber de Oliveira Costa
Cc: Jeremy Fitzhardinge, John Stoffel, kvm-devel, linux-kernel,
Ingo Molnar, virtualization
[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
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
--
------------- Laurent.Vivier@bull.net --------------
"Software is hard" - Donald Knuth
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 7:45 ` Laurent Vivier
0 siblings, 0 replies; 17+ messages in thread
From: Laurent Vivier @ 2007-08-21 7:45 UTC (permalink / raw)
To: Glauber de Oliveira Costa
Cc: Jeremy Fitzhardinge, kvm-devel, John Stoffel, linux-kernel,
virtualization
[-- Attachment #1.1: Type: text/plain, Size: 2042 bytes --]
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
--
------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org --------------
"Software is hard" - Donald Knuth
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 315 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
[-- Attachment #3: Type: text/plain, Size: 186 bytes --]
_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 17:46 ` Glauber de Oliveira Costa
0 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-21 17:46 UTC (permalink / raw)
To: Laurent Vivier
Cc: Jeremy Fitzhardinge, John Stoffel, kvm-devel, linux-kernel,
Ingo Molnar, virtualization
On 8/21/07, Laurent Vivier <Laurent.Vivier@bull.net> 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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 17:46 ` Glauber de Oliveira Costa
0 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-21 17:46 UTC (permalink / raw)
To: Laurent Vivier
Cc: Jeremy Fitzhardinge, kvm-devel, John Stoffel, linux-kernel,
virtualization
On 8/21/07, Laurent Vivier <Laurent.Vivier-6ktuUTfB/bM@public.gmane.org> 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."
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
2007-08-21 7:45 ` Laurent Vivier
(?)
(?)
@ 2007-08-21 17:46 ` Glauber de Oliveira Costa
-1 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-21 17:46 UTC (permalink / raw)
To: Laurent Vivier
Cc: kvm-devel, John Stoffel, linux-kernel, virtualization,
Ingo Molnar
On 8/21/07, Laurent Vivier <Laurent.Vivier@bull.net> 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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
2007-08-20 20:34 ` Glauber de Oliveira Costa
(?)
(?)
@ 2007-08-21 7:45 ` Laurent Vivier
-1 siblings, 0 replies; 17+ messages in thread
From: Laurent Vivier @ 2007-08-21 7:45 UTC (permalink / raw)
To: Glauber de Oliveira Costa
Cc: kvm-devel, John Stoffel, linux-kernel, virtualization,
Ingo Molnar
[-- Attachment #1.1: Type: text/plain, Size: 2022 bytes --]
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
--
------------- Laurent.Vivier@bull.net --------------
"Software is hard" - Donald Knuth
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [kvm-devel] Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 8:06 ` Christian Borntraeger
0 siblings, 0 replies; 17+ messages in thread
From: Christian Borntraeger @ 2007-08-21 8:06 UTC (permalink / raw)
To: kvm-devel
Cc: Glauber de Oliveira Costa, laurent.vivier@bull.net,
Jeremy Fitzhardinge, John Stoffel, linux-kernel, virtualization
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 8:06 ` Christian Borntraeger
0 siblings, 0 replies; 17+ messages in thread
From: Christian Borntraeger @ 2007-08-21 8:06 UTC (permalink / raw)
To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: Jeremy Fitzhardinge, John Stoffel, linux-kernel, virtualization
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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [kvm-devel] Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
2007-08-21 8:06 ` Christian Borntraeger
(?)
@ 2007-08-21 17:47 ` Glauber de Oliveira Costa
-1 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-21 17:47 UTC (permalink / raw)
To: Christian Borntraeger
Cc: kvm-devel, laurent.vivier@bull.net, John Stoffel, linux-kernel,
virtualization
On 8/21/07, Christian Borntraeger <borntraeger@de.ibm.com> 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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [kvm-devel] Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 17:47 ` Glauber de Oliveira Costa
0 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-21 17:47 UTC (permalink / raw)
To: Christian Borntraeger
Cc: kvm-devel, laurent.vivier@bull.net, Jeremy Fitzhardinge,
John Stoffel, linux-kernel, virtualization
On 8/21/07, Christian Borntraeger <borntraeger@de.ibm.com> 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."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
@ 2007-08-21 17:47 ` Glauber de Oliveira Costa
0 siblings, 0 replies; 17+ messages in thread
From: Glauber de Oliveira Costa @ 2007-08-21 17:47 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Jeremy Fitzhardinge, kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
John Stoffel, linux-kernel, virtualization
On 8/21/07, Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> 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."
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [kvm-devel] Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
2007-08-20 20:34 ` Glauber de Oliveira Costa
` (3 preceding siblings ...)
(?)
@ 2007-08-21 8:06 ` Christian Borntraeger
-1 siblings, 0 replies; 17+ messages in thread
From: Christian Borntraeger @ 2007-08-21 8:06 UTC (permalink / raw)
To: kvm-devel
Cc: John Stoffel, linux-kernel, virtualization,
laurent.vivier@bull.net
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
^ permalink raw reply [flat|nested] 17+ messages in thread