On 12.02.2018 16:38, Cornelia Huck wrote: > On Mon, 12 Feb 2018 13:14:29 +0100 > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote: > >> This series consolidates patches around a performance issue >> caused by the usage of QMP query-cpus. > > Thank you for consolidating this; it was a bit hard to follow the > different discussions. > >> >> A performance issue was found in an OpenStack environment, where >> ceilometer was collecting domain statistics with libvirt. The domain >> statistics reported by libvirt include the vCPU halted state, which >> in turn is retrieved with QMP query-cpus. >> >> This causes two issues: >> 1. Performance: on most architectures query-cpus needs to issue a KVM ioctl >> to find out whether a vCPU was halted. This is not the case for s390 >> but query-cpus is always causing the vCPU to exit the VM. >> >> 2. Semantics: on x86 and other architectures, halted is a highly transient >> state, which is likely to have already changed shortly after the state >> information has been retrieved. This is not the case for s390, where >> halted is an indication that the vCPU is stopped, meaning its not >> available to the guest operating system until it has been restarted. >> >> The following patches help to alleviate the issues: >> >> Patch 1/3: >> Adds architecture specific data to the QMP CpuInfo type, exposing >> the existing s390 cpu-state in QMP. The cpu-state is a representation >> more adequate than the ambiguous 'halted' condition. >> >> Changes since original v2: >> - fixed cpu-state usage in hw/intc/s390_flic.c, necessary because >> master was updated in the meantime >> - removed superfluous newline while printing cpu-state > > So this is adding s390x info in query-cpus (presumably for legacy > callers?)... > Yeah, as long as we have the slow call, the fast data should be in there as well. [...] > > ...this is adding the new query-cpus-fast... > [...] > > ...and this is adding the s390x state to query-cpus-fast, right? > Exactly.
-- Regards, Viktor Mihajlovski