From: Luiz Capitulino <lcapitulino@redhat.com>
To: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, armbru@redhat.com, eblake@redhat.com,
ehabkost@redhat.com, berrange@redhat.com,
Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] qmp: add query-cpus-fast
Date: Thu, 8 Feb 2018 08:59:30 -0500 [thread overview]
Message-ID: <20180208085930.63c83bac@redhat.com> (raw)
In-Reply-To: <5cb72a0b-5ff0-42ab-d992-ccdd2a565cfa@linux.vnet.ibm.com>
On Thu, 8 Feb 2018 08:41:31 +0100
Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote:
> On 07.02.2018 18:50, Luiz Capitulino wrote:
> > The query-cpus command has an extremely serious side effect:
> > it always interrupt all running vCPUs so that they can run
> > ioctl calls. This can cause a huge performance degradation for
> > some workloads. And most of the information retrieved by the
> > ioctl calls are not even used by query-cpus.
> >
> > This commit introduces a replacement for query-cpus called
> > query-cpus-fast, which has the following features:
> >
> > o Never interrupt vCPUs threads. query-cpus-fast only returns
> > vCPU information maintained by QEMU itself, which should be
> > sufficient for most management software needs
> >
> > o Make "halted" field optional: we only return it if the
> > halted state is maintained by QEMU. But this also gives
> > the option of dropping the field in the future (see below)
> >
> > o Drop irrelevant fields such as "current", "pc" and "arch"
> I disagree that arch is irrelevant and would strongly suggest to keep
> arch and arch-specific fields. At least in the case of s390 there's a
> cpu_state field that can be obtained cheaply.
The arch name can be queried with query-target. The only other
arch field I'm dropping is pc, which should be considered debug
only if anything.
Also, if this need to query CPU registers increase, then we
probably should port 'info registers' to QMP. Otherwise, we'll
eventually run into the performance problem once again.
> [...]
> > diff --git a/cpus.c b/cpus.c
> > index 2cb0af9b22..3b68a8146c 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -2083,6 +2083,50 @@ CpuInfoList *qmp_query_cpus(Error **errp)
> > return head;
> > }
> >
> > +/*
> > + * fast means: we NEVER interrupt vCPU threads to retrieve
> > + * information from KVM.
> > + */
> > +CpuInfo2List *qmp_query_cpus_fast(Error **errp)
> > +{
> > + MachineState *ms = MACHINE(qdev_get_machine());
> > + MachineClass *mc = MACHINE_GET_CLASS(ms);
> > + CpuInfo2List *head = NULL, *cur_item = NULL;
> > + CPUState *cpu;
> > +
> > + CPU_FOREACH(cpu) {
> > + CpuInfo2List *info = g_malloc0(sizeof(*info));
> > + info->value = g_malloc0(sizeof(*info->value));
> > +
> > + info->value->cpu_index = cpu->cpu_index;
> > + info->value->qom_path = object_get_canonical_path(OBJECT(cpu));
> > + info->value->thread_id = cpu->thread_id;
> > +
> > + info->value->has_props = !!mc->cpu_index_to_instance_props;
> > + if (info->value->has_props) {
> > + CpuInstanceProperties *props;
> > + props = g_malloc0(sizeof(*props));
> > + *props = mc->cpu_index_to_instance_props(ms, cpu->cpu_index);
> > + info->value->props = props;
> > + }
> > +
> > + /* if in kernel irqchip is used, we don't have 'halted' */
> > + info->value->has_halted = !kvm_irqchip_in_kernel();
> This is definitely not true for s390. Externally observable CPU state
> changes are handled by QEMU there. We may still drop halted if we add a
> more appropriate arch-specific field.
> > + if (info->value->has_halted) {
> > + info->value->halted = cpu->halted;
> > + }
> [...]
>
next prev parent reply other threads:[~2018-02-08 13:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 17:50 [Qemu-devel] [PATCH 0/2] qmp: add query-cpus-fast Luiz Capitulino
2018-02-07 17:50 ` [Qemu-devel] [PATCH 1/2] " Luiz Capitulino
2018-02-07 18:49 ` Eric Blake
2018-02-08 7:41 ` Viktor Mihajlovski
2018-02-08 10:13 ` Viktor Mihajlovski
2018-02-08 13:59 ` Luiz Capitulino [this message]
2018-02-08 19:59 ` Eduardo Habkost
2018-02-08 20:59 ` Eric Blake
2018-02-08 21:41 ` Eduardo Habkost
2018-02-09 8:13 ` Viktor Mihajlovski
2018-02-07 17:50 ` [Qemu-devel] [PATCH 2/2] qmp: document query-cpus performance issue Luiz Capitulino
2018-02-07 18:50 ` Eric Blake
2018-02-07 19:14 ` Luiz Capitulino
2018-02-08 9:29 ` Daniel P. Berrangé
2018-02-08 14:00 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180208085930.63c83bac@redhat.com \
--to=lcapitulino@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=eblake@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mihajlov@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).