From: Eric Blake <eblake@redhat.com>
To: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Cc: agraf@suse.de, ehabkost@redhat.com, armbru@redhat.com,
cohuck@redhat.com, david@redhat.com, dgilbert@redhat.com,
borntraeger@de.ibm.com, qemu-s390x@nongnu.org,
pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCHv3 2/4] qmp: add query-cpus-fast
Date: Thu, 15 Feb 2018 08:19:57 -0600 [thread overview]
Message-ID: <3b41b0f0-09cf-9e43-bfa4-617335d76584@redhat.com> (raw)
In-Reply-To: <1518690027-31318-3-git-send-email-mihajlov@linux.vnet.ibm.com>
On 02/15/2018 04:20 AM, Viktor Mihajlovski wrote:
> From: Luiz Capitulino <lcapitulino@redhat.com>
>
> The query-cpus command has an extremely serious side effect:
> it always interrupts 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 Drop "halted" field as it can not retrieved in a fast
s/can not retrieved/cannot be retrieved/
> way on most architectures
>
> o Drop irrelevant fields such as "current", "pc" and "arch"
>
> o Rename some fields for better clarification & proper naming
> standard
>
> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Acked-by: Eric Blake <eblake@redhat.com>
> ---
> +++ b/hmp-commands-info.hx
> @@ -160,6 +160,20 @@ Show infos for each CPU.
Pre-existing, but while we are here, it wouldn't hurt to do
s/infos/information/
> ETEXI
>
> {
> + .name = "cpus_fast",
> + .args_type = "",
> + .params = "",
> + .help = "show information for each CPU without interrupting them",
> + .cmd = hmp_info_cpus_fast,
> + },
> +
> +STEXI
> +@item info cpus_fast
> +@findex info cpus_fast
> +Show infos for each CPU without performance penalty.
and again here, where you copied and pasted.
You know, we have no back-compat guarantees on HMP. We could make 'info
cpu' just ALWAYS call query-cpus-fast, with no HMP counterpart for the
slower query-cpus, and without needing a deprecation period. But I'll
leave that up to David if that makes more sense.
> +++ b/hmp.c
> @@ -410,6 +410,20 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
> qapi_free_CpuInfoList(cpu_list);
> }
>
> +void hmp_info_cpus_fast(Monitor *mon, const QDict *qdict)
> +{
> + CpuInfoFastList *head, *cpu;
> +
> + head = qmp_query_cpus_fast(NULL);
> +
> + for (cpu = head; cpu; cpu = cpu->next) {
> + monitor_printf(mon, " CPU #%" PRId64 ":", cpu->value->cpu_index);
> + monitor_printf(mon, " thread-id=%" PRId64 "\n", cpu->value->thread_id);
> + }
This is particularly true since your HMP implementation is not even
printing all the information returned by query-cpus-fast!
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2018-02-15 14:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 10:20 [Qemu-devel] [PATCHv3 0/4] ] add query-cpu-fast and related s390 changes Viktor Mihajlovski
2018-02-15 10:20 ` [Qemu-devel] [PATCHv3 1/4] qmp: expose s390-specific CPU info Viktor Mihajlovski
2018-02-15 10:20 ` [Qemu-devel] [PATCHv3 2/4] qmp: add query-cpus-fast Viktor Mihajlovski
2018-02-15 14:19 ` Eric Blake [this message]
2018-02-15 14:40 ` Viktor Mihajlovski
2018-02-15 14:53 ` Eric Blake
2018-02-15 14:59 ` Viktor Mihajlovski
2018-02-15 10:20 ` [Qemu-devel] [PATCHv3 3/4] qmp: add architecture specific cpu data for query-cpus-fast Viktor Mihajlovski
2018-02-15 10:20 ` [Qemu-devel] [PATCHv3 4/4] qemu-doc: deprecate query-cpus and info cpus Viktor Mihajlovski
2018-02-15 14:23 ` Eric Blake
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=3b41b0f0-09cf-9e43-bfa4-617335d76584@redhat.com \
--to=eblake@redhat.com \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mihajlov@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
/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).