On Mon, Dec 16, 2024 at 07:02:44PM -0300, Fabricio Duarte wrote:
The fields are in nanoseconds, not microseconds. Also fixes the description of `vcpu.<num>.wait`, as it does not actually represent the time waiting on I/O.
Sorry for responding so late to your patch and thank you for the contribution. Just a few small nitpicks that I'll fix before pushing: 1) It's better to wrap the commit message so that it does not have such long lines, and
Signed-off-by: Fabricio Duarte <fabricio.duarte.jr@xxxxxxxxx> --- docs/manpages/virsh.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 2e525d3fac..b0a21e019a 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2428,14 +2428,14 @@ When selecting the *--state* group the following fields are returned: * ``vcpu.<num>.state`` - state of the virtual CPU <num>, as number from virVcpuState enum * ``vcpu.<num>.time`` - virtual cpu time spent by virtual - CPU <num> (in microseconds) -* ``vcpu.<num>.wait`` - virtual cpu time spent by virtual - CPU <num> waiting on I/O (in microseconds) + CPU <num> (in nanoseconds) +* ``vcpu.<num>.wait`` - time the vCPU <num> wants to run, but the host + scheduler has something else running ahead of it (in nanoseconds)
2) I would rather use the short description about waiting in runqueue. Having said that...
* ``vcpu.<num>.halted`` - virtual CPU <num> is halted: yes or no (may indicate the processor is idle or even disabled, depending on the architecture) * ``vcpu.<num>.delay`` - time the vCPU <num> thread was enqueued by the - host scheduler, but was waiting in the queue instead of running. + host scheduler, but was waiting in the queue instead of running (in nanoseconds). Exposed to the VM as a steal time.
that makes it the same message as this, even though we gather the info from different places. I went through a really deep dive into the differences just to review this and I can't think of any other difference than the wait being calculated maybe more precisely, but only if CONFIG_SCHED_INFO is enabled. Anyway, I'll fix up these two things and push the patch with my Reviewed-by: Martin Kletzander <mkletzan@xxxxxxxxxx> Feel free to send any amendments if I made a mistake anywhere. Thanks again for your contribution and have a nice day!
This group of statistics also reports additional hypervisor-originating per-vCPU -- 2.39.2
Attachment:
signature.asc
Description: PGP signature
