Re: [vdsm] Change in vdsm[master]: report cpuUser and cpuSys separately
by Ryan Harper
* Mark Wu <wudxw(a)linux.vnet.ibm.com> [2012-09-07 05:00]:
> Mark Wu has posted comments on this change.
>
> Change subject: report cpuUser and cpuSys separately
> ......................................................................
>
>
> Patch Set 1:
>
> Here's the cpustats of a running vm:
>
> virsh # cpu-stats 3
> CPU0:
> cpu_time 152.626922854 seconds
> CPU1:
> cpu_time 460.343462849 seconds
> CPU2:
> cpu_time 37.569566994 seconds
> CPU3:
> cpu_time 21.092908393 seconds
> Total:
> cpu_time 671.632861090 seconds
> user_time 3.440000000 seconds
> system_time 18.380000000 seconds
>
> You can see cpu_time is much bigger than the sum of user_time and
> system_time, because the guest time is not reported here. So most cpu
> time is used to run guest code. It makes sense! For a qemu-kvm
> process, user_time represents the time used by qemu, and system_time
> represents the time used by kvm module, which doesn't contain guest
> time. I am not sure if this is what you expect. It could be a little
> bit confusing for user.
I think it's useful to split the data out seperately for debugging
purposes, not clear to me that the user is interested in the break down.
Advanced performance tuning will definitely want to observe the data as
well as users looking to debug issues.
I don't see the harm in adding additional information.
>
> --
> To view, visit http://gerrit.ovirt.org/7718
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I663ad25ff3ff5ce426b5159b6c9a65b7f5167605
> Gerrit-PatchSet: 1
> Gerrit-Project: vdsm
> Gerrit-Branch: master
> Gerrit-Owner: Laszlo Hornyak <lhornyak(a)redhat.com>
> Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com>
> Gerrit-Reviewer: Gal Hammer <ghammer(a)redhat.com>
> Gerrit-Reviewer: Laszlo Hornyak <lhornyak(a)redhat.com>
> Gerrit-Reviewer: Mark Wu <wudxw(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: Royce Lv <lvroyce(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: oVirt Jenkins CI Server
> _______________________________________________
> vdsm-patches mailing list
> vdsm-patches(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
11 years, 8 months
Sync mom and vdsm releases
by agl＠us.ibm.com
Hi Dan, et al:
Since vdsm and MOM are now evolving together it seems appropriate that we
coordinate their releases. Could you provide me with some information on how
the vdsm releases are done? I will take care of releasing MOM (including Fedora
packages, etc) but I just need to know when vdsm will release. Also, we need to
keep the 'Requires:' up to date in the vdsm spec file.
Thanks.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 8 months
Cancelled: ovirt network
by lpeer＠redhat.com
A single instance of the following meeting has been cancelled:
Subject: ovirt network
Organiser: "Livnat Peer" <lpeer(a)redhat.com>
Time: Wednesday, 19 September, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem
Invitees: engine-devel(a)ovirt.org; vdsm-devel(a)lists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.com; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck(a)redhat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ...
*~*~*~*~*~*~*~*~*~*
I'm on vacation Sep 19th, cancelling this meeting instance.
If you want to have the meeting please send a new invite to the dev lists.
Thanks, Livnat
11 years, 8 months
[RFC] Implied UUIDs in API
by smizrahi＠redhat.com
Hi, in the API a lot of IDs get passed around are UUIDs.
The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you.
I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs.
It's another restriction we can remove from the interface simplifying the code and the interface.
Just to be clear I'm not saying that we should stop using UUIDs.
For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value.
If for some reason we choose to change the format of task IDs. There will be no need to change the interface.
The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values.
11 years, 8 months
