The aim of these four patches is to introduce Virtual Machine time accounting.
_Ingo_, as these patches modify files of the scheduler, could you have a look to
them, please ?
[PATCH 1/4] as recent CPUs introduce a third running state, after "user" and
"system", we need a new field, "guest", in cpustat to store the time used by
the CPU to run virtual CPU. Modify /proc/stat to display this new field.
[PATCH 2/4] like for cpustat, introduce the "gtime" (guest time of the task) and
"cgtime" (guest time of the task children) fields for the
tasks. Modify signal_struct and task_struct. Modify /proc/<pid>/stat to display
these new fields.
[PATCH 3/4] modify account_system_time() to add cputime to cpustat->guest if we
are running a VCPU. We add this cputime to cpustat->user instead of
cpustat->system because this part of KVM code is in fact user code although it
is executed in the kernel. We duplicate VCPU time between guest and user to
allow an unmodified "top(1)" to display correct value. A modified "top(1)" is
able to display good cpu user time and cpu guest time by subtracting cpu guest
time from cpu user time. Update "gtime" and "cgtime" in signal_struct and
task_struct accordingly.
[PATCH 4/4] Modify KVM to update guest time accounting.
Signed-off-by: Laurent Vivier <[email protected]>
--
------------- [email protected] --------------
"Software is hard" - Donald Knuth
Laurent Vivier wrote:
> The aim of these four patches is to introduce Virtual Machine time accounting.
>
1-3 look good to me. 4 needs minor edits...
--
error compiling committee.c: too many arguments to function
Laurent> The aim of these four patches is to introduce Virtual Machine
Laurent> time accounting.
So what does this buy us? What increased functionality?
Laurent> [PATCH 1/4] as recent CPUs introduce a third running state,
Laurent> after "user" and "system", we need a new field, "guest", in
Laurent> cpustat to store the time used by the CPU to run virtual
Laurent> CPU. Modify /proc/stat to display this new field.
What happens when you have multiple guests, is this state cummulative?
I've glanced over these patches and the #ifdefs are ugly..., esp since
the overhead seems to exist even if you don't run any Guest CPUs. Or
whatever you're doing here.
Please justify this patch more in terms of what it provides and why
it's a good thing to have.
Thanks,
John
Hi John,
John Stoffel wrote:
>
> Laurent> The aim of these four patches is to introduce Virtual Machine
> Laurent> time accounting.
>
> So what does this buy us? What increased functionality?
>
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
> Laurent> [PATCH 1/4] as recent CPUs introduce a third running state,
> Laurent> after "user" and "system", we need a new field, "guest", in
> Laurent> cpustat to store the time used by the CPU to run virtual
> Laurent> CPU. Modify /proc/stat to display this new field.
>
> What happens when you have multiple guests, is this state cummulative?
Yes, like system time and user time are.
> I've glanced over these patches and the #ifdefs are ugly..., esp since
#ifdefs are ugly, I agree... I can remove them.
But "#ifdef" allows to save space and time (and it is not a beauty show).
> the overhead seems to exist even if you don't run any Guest CPUs. Or
> whatever you're doing here.
Can you explain ?
> Please justify this patch more in terms of what it provides and why
> it's a good thing to have.
Well... it provides the time spent by CPUs in virtual CPUs.
It is usefull only if you run Virtual Machine on your host (like KVM, lguest,
kqemu...) to know how many time your CPUs dedicate to virtual machine execution.
It's a good thing to have like user time and system time are good things to
have... do you use 'top' or 'time' sometime ?
Laurent
--
------------- [email protected] --------------
"Software is hard" - Donald Knuth
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
guest context, couldn't it provide the breakdown between user and guest
time (ditto lguest)?
J
On Mon, 2007-08-20 at 09:13 -0700, Jeremy Fitzhardinge wrote:
> 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
> guest context, couldn't it provide the breakdown between user and guest
> time (ditto lguest)?
No, unfortunately it's accumulated as system time.
Rusty.
Jeremy Fitzhardinge wrote:
> 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
> guest context, couldn't it provide the breakdown between user and guest
> time (ditto lguest)?
>
qemu doesn't (and shouldn't) do accounting; that's best done by
interrupt driven code.
The patches do account for guest time in a separate counter; guest time
is added to both user time and the new counter. This allows an old
'top' to see guest time (accounted as user time), and a new 'top' to
separate guest time and user time by performing the appropriate
mathematical operation.
--
error compiling committee.c: too many arguments to function