* xc_domain_getfullinfo() gone
@ 2005-05-13 14:40 Andrew Theurer
2005-05-13 14:45 ` Kip Macy
2005-05-13 14:57 ` Kip Macy
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Theurer @ 2005-05-13 14:40 UTC (permalink / raw)
To: xen-devel
I noticed this was gone from libxc. Would there be any objection to
adding xc_domain_get_vcpu_info? I am interested in querying the
cpu_time for each vcpu for a utility that does something like:
vm-stat
cpu[ util] domN-vcpuM[util]...domY-vcpuZ[util]
------------ --------------------------------------
cpu0[075.4] dom0-vcpu0[000.3] dom1-vcpu1[075.1]
cpu1[083.7] dom1-vcpu2[083.7]
cpu2[069.2] dom1-vcpu3[069.2]
cpu3[075.9] dom1-vcpu0[075.9]
< time interval>
cpu0[100.0] dom0-vcpu0[000.5] dom1-vcpu1[099.5]
cpu1[099.8] dom1-vcpu2[099.8]
cpu2[099.8] dom1-vcpu3[099.8]
cpu3[099.8] dom1-vcpu0[099.8]
cpu0[100.0] dom0-vcpu0[000.3] dom1-vcpu1[099.7]
cpu1[099.7] dom1-vcpu2[099.7]
cpu2[099.7] dom1-vcpu3[099.7]
cpu3[099.7] dom1-vcpu0[099.7]
cpu0[100.0] dom0-vcpu0[000.6] dom1-vcpu1[099.4]
cpu1[099.7] dom1-vcpu2[099.7]
cpu2[099.7] dom1-vcpu3[099.7]
cpu3[101.4] dom1-vcpu0[101.4]
And while we're on this subject, I wanted to track, per phys cpu,
exec_domain context switches, and store this as ctx_switches in
schedule_data struct. I believe tracking context switches would be a
good stat to have, for example, to expose problems like high domU
traffic networking on one cpu system. Any objection to this or suggestions?
Thanks,
-Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xc_domain_getfullinfo() gone
2005-05-13 14:40 xc_domain_getfullinfo() gone Andrew Theurer
@ 2005-05-13 14:45 ` Kip Macy
2005-05-13 14:57 ` Kip Macy
1 sibling, 0 replies; 4+ messages in thread
From: Kip Macy @ 2005-05-13 14:45 UTC (permalink / raw)
To: Andrew Theurer; +Cc: xen-devel
It is already there. It hasn't been exported to python as the main
purpose is to query register state. You're welcome to add it.
-Kip
On 5/13/05, Andrew Theurer <habanero@us.ibm.com> wrote:
> I noticed this was gone from libxc. Would there be any objection to
> adding xc_domain_get_vcpu_info? I am interested in querying the
> cpu_time for each vcpu for a utility that does something like:
>
> vm-stat
>
> cpu[ util] domN-vcpuM[util]...domY-vcpuZ[util]
> ------------ --------------------------------------
> cpu0[075.4] dom0-vcpu0[000.3] dom1-vcpu1[075.1]
> cpu1[083.7] dom1-vcpu2[083.7]
> cpu2[069.2] dom1-vcpu3[069.2]
> cpu3[075.9] dom1-vcpu0[075.9]
> < time interval>
> cpu0[100.0] dom0-vcpu0[000.5] dom1-vcpu1[099.5]
> cpu1[099.8] dom1-vcpu2[099.8]
> cpu2[099.8] dom1-vcpu3[099.8]
> cpu3[099.8] dom1-vcpu0[099.8]
>
> cpu0[100.0] dom0-vcpu0[000.3] dom1-vcpu1[099.7]
> cpu1[099.7] dom1-vcpu2[099.7]
> cpu2[099.7] dom1-vcpu3[099.7]
> cpu3[099.7] dom1-vcpu0[099.7]
>
> cpu0[100.0] dom0-vcpu0[000.6] dom1-vcpu1[099.4]
> cpu1[099.7] dom1-vcpu2[099.7]
> cpu2[099.7] dom1-vcpu3[099.7]
> cpu3[101.4] dom1-vcpu0[101.4]
>
> And while we're on this subject, I wanted to track, per phys cpu,
> exec_domain context switches, and store this as ctx_switches in
> schedule_data struct. I believe tracking context switches would be a
> good stat to have, for example, to expose problems like high domU
> traffic networking on one cpu system. Any objection to this or suggestions?
>
> Thanks,
>
> -Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xc_domain_getfullinfo() gone
2005-05-13 14:40 xc_domain_getfullinfo() gone Andrew Theurer
2005-05-13 14:45 ` Kip Macy
@ 2005-05-13 14:57 ` Kip Macy
1 sibling, 0 replies; 4+ messages in thread
From: Kip Macy @ 2005-05-13 14:57 UTC (permalink / raw)
To: Andrew Theurer; +Cc: xen-devel
Never mind, I was thinking get_vcpu_context, but per-cpu time is
already available in get_vcpu_context.
-Kip
On 5/13/05, Andrew Theurer <habanero@us.ibm.com> wrote:
> I noticed this was gone from libxc. Would there be any objection to
> adding xc_domain_get_vcpu_info? I am interested in querying the
> cpu_time for each vcpu for a utility that does something like:
>
> vm-stat
>
> cpu[ util] domN-vcpuM[util]...domY-vcpuZ[util]
> ------------ --------------------------------------
> cpu0[075.4] dom0-vcpu0[000.3] dom1-vcpu1[075.1]
> cpu1[083.7] dom1-vcpu2[083.7]
> cpu2[069.2] dom1-vcpu3[069.2]
> cpu3[075.9] dom1-vcpu0[075.9]
> < time interval>
> cpu0[100.0] dom0-vcpu0[000.5] dom1-vcpu1[099.5]
> cpu1[099.8] dom1-vcpu2[099.8]
> cpu2[099.8] dom1-vcpu3[099.8]
> cpu3[099.8] dom1-vcpu0[099.8]
>
> cpu0[100.0] dom0-vcpu0[000.3] dom1-vcpu1[099.7]
> cpu1[099.7] dom1-vcpu2[099.7]
> cpu2[099.7] dom1-vcpu3[099.7]
> cpu3[099.7] dom1-vcpu0[099.7]
>
> cpu0[100.0] dom0-vcpu0[000.6] dom1-vcpu1[099.4]
> cpu1[099.7] dom1-vcpu2[099.7]
> cpu2[099.7] dom1-vcpu3[099.7]
> cpu3[101.4] dom1-vcpu0[101.4]
>
> And while we're on this subject, I wanted to track, per phys cpu,
> exec_domain context switches, and store this as ctx_switches in
> schedule_data struct. I believe tracking context switches would be a
> good stat to have, for example, to expose problems like high domU
> traffic networking on one cpu system. Any objection to this or suggestions?
>
> Thanks,
>
> -Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: xc_domain_getfullinfo() gone
@ 2005-05-13 17:02 Ian Pratt
0 siblings, 0 replies; 4+ messages in thread
From: Ian Pratt @ 2005-05-13 17:02 UTC (permalink / raw)
To: Andrew Theurer, xen-devel
> And while we're on this subject, I wanted to track, per phys
> cpu, exec_domain context switches, and store this as
> ctx_switches in schedule_data struct. I believe tracking
> context switches would be a good stat to have, for example,
> to expose problems like high domU traffic networking on one
> cpu system. Any objection to this or suggestions?
context switches per CPU woul be a useful thing to have -- we already
record this in the s/w perf counters.
Ian
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-05-13 17:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-13 14:40 xc_domain_getfullinfo() gone Andrew Theurer
2005-05-13 14:45 ` Kip Macy
2005-05-13 14:57 ` Kip Macy
-- strict thread matches above, loose matches on Subject: below --
2005-05-13 17:02 Ian Pratt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.