AW: High xen_hypercall_sched_op usage

[Klaus Darilion <klaus.darilion@xxxxxx>]

Hi Juergen!

> -----Ursprüngliche Nachricht-----
> Von: Juergen Gross <jgross@xxxxxxxx>
> Gesendet: Dienstag, 14. November 2023 17:14
> An: Klaus Darilion <klaus.darilion@xxxxxx>; xen-users@xxxxxxxxxxxxx
> Betreff: Re: High xen_hypercall_sched_op usage
> 
> > So most of CPU time is consumed by xen_hypercall_sched_op. IS it normal
> that
> > xen_hypercall_sched_op
> >
> > basically eats up all CPU? Is this an indication of some underlying problem?
> Or
> > is that normal?
> 
> In a PV guest the sched_op hypercall is used e.g. for going to idle. I guess
> you are adding up all idle time to the sched_op hypercall.

What does this mean? Idle Time is measured as "system cpu usage"? Further, the 
VM was getting real slow while that amount increase, so I think the VM was not 
idle but waiting for something.

> >
> > b1) So, as the VMs are not pinned, it may happen that the same CPU is
> used for
> > the dom0 and the domU. But why? There are 128vCPUs available, and only
> 112vCPUs
> > used. Is XEN not smart enough to use all vCPUs?
> 
> You are mixing up vcpus and physical cpus.
> 
> A vcpu is a virtualized cpu presented to the guest. It can run on any physical
> cpu if no pinning etc. is involved.

Will it be beneficial if all VMs have hard pinned CPUs?

> > b2) Sometimes I see that 2 vCPUs use the same CPU? How can that be that
> a CPUs
> > is used concurrently for 2 vCPUs? And why, as there are plenty of vCPUs
> left?
> >
> > root@cc6-vie:/home/darilion# xl vcpu-list|grep 102
> >
> > Name                                ID  VCPU   CPU State   Time(s) Affinity
> > (Hard / Soft)
> >
> > domU1                                  3    67  102   r--  119730.3  all / 
> > 0-127
> >
> > domU1                                  3    77  102   -b-  119224.1  all / 
> > 0-127
> 
> This shows that vcpu 77 is blocked (AKA idle), so it is not waiting for a
> physical cpu to become free. The Xen credit2 scheduler will prefer to try
> running only a single vcpu on a core, as long as enough cores are available
> to achieve that goal. This maximizes performance, but it can result in a
> situation like the one you are seeing: in case the idle vcpu currently hooked
> to the same cpu as an already running one wants to run again, it needs to
> switch cpus.

Thanks for the explanation.

Regards
Klaus