From: Peter Krempa <pkrempa@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Michal Novotny <minovotn@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] New cpu-max field in query-machines QMP command output
Date: Tue, 09 Apr 2013 15:15:55 +0200 [thread overview]
Message-ID: <5164148B.4020000@redhat.com> (raw)
In-Reply-To: <20130409090613.70dd97e3@redhat.com>
On 04/09/13 15:06, Luiz Capitulino wrote:
> On Mon, 08 Apr 2013 11:14:32 -0600
> Eric Blake <eblake@redhat.com> wrote:
>
>> On 04/08/2013 10:41 AM, Michal Novotny wrote:
>>> Alter the query-machines QMP command to output information about
>>> maximum number of CPUs for each machine type with default value
>>> set to 1 in case the number of max_cpus is not set.
>>>
>>> Signed-off-by: Michal Novotny <minovotn@redhat.com>
>>> ---
>>> qapi-schema.json | 4 +++-
>>> vl.c | 1 +
>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/qapi-schema.json b/qapi-schema.json
>>> index db542f6..689ca8d 100644
>>> --- a/qapi-schema.json
>>> +++ b/qapi-schema.json
>>> @@ -2861,11 +2861,13 @@
>>> #
>>> # @default: #optional whether the machine is default
>>> #
>>> +# @cpu-max: maximum number of CPUs supported by the machine type
>>
>> Typically, when adding a field in a later version than the original
>> introduction of the datatype, we add '(since 1.5)' to make it obvious
>> when to expect the field. However, as nothing (currently) enforces this
>> rule, I think such an addition is minor enough that it wouldn't
>> invalidate the use of my:
>
> Oh, it turns out I was making some confusion with this patch and
> didn't realize it was extending the query-machines command.
>
> I don't mean there's anything wrong with it, but my question is: doesn't
> this patch invalidates query-cpu-max?
Unfortunately, for libvirt query-cpu-max isn't really usable as it needs
us to start qemu with the correct machine type. This would increase
overhead as we would need to start the qemu process with a safe number
of cpus, use query-cpu-max and then restart the process.
The information added in the query-machines output can on the other hand
be cached (we are already doing this for the machine types) and used
later from the cache without increasing overhead.
So yes, I think it invalidates query-cpu-max and it can be removed in
case it wasn't released.
Peter
>
> PS: I can add the '(since 1.5)' line myself.
>
>>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
>>
>
>
prev parent reply other threads:[~2013-04-09 13:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 16:41 [Qemu-devel] [PATCH v2] New cpu-max field in query-machines QMP command output Michal Novotny
2013-04-08 16:35 ` [Qemu-devel] Fwd: " Michal Novotny
2013-04-08 17:14 ` [Qemu-devel] " Eric Blake
2013-04-09 13:06 ` Luiz Capitulino
2013-04-09 13:09 ` Michal Novotny
2013-04-09 13:15 ` Luiz Capitulino
2013-04-09 13:32 ` Michal Novotny
2013-04-09 13:42 ` Luiz Capitulino
2013-04-09 13:59 ` Michal Novotny
2013-04-09 13:15 ` Peter Krempa [this message]
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=5164148B.4020000@redhat.com \
--to=pkrempa@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=minovotn@redhat.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).