From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
eblake@redhat.com, armbru@redhat.com, agl@us.ibm.com
Subject: Re: [Qemu-devel] [PATCH 6/6] qmp: add balloon-get-memory-stats & event
Date: Fri, 17 Feb 2012 15:38:27 -0600 [thread overview]
Message-ID: <20120217213827.GD20920@illuin> (raw)
In-Reply-To: <4F3EB393.8090605@us.ibm.com>
On Fri, Feb 17, 2012 at 02:07:47PM -0600, Anthony Liguori wrote:
> On 02/17/2012 11:09 AM, Michael Roth wrote:
> >On Fri, Feb 17, 2012 at 10:55:41AM -0600, Anthony Liguori wrote:
> >>On 02/08/2012 02:30 PM, Luiz Capitulino wrote:
> >>>This commit adds a QMP API for the guest provided memory statistics
> >>>(long disabled by commit 07b0403dfc2b2ac179ae5b48105096cc2d03375a).
> >>>
> >>>The approach taken by the original commit
> >>>(625a5befc2e3200b396594f002218d235e375da5) was to extend the
> >>>query-balloon command. It introduced a severe bug though: query-balloon
> >>>would hang if the guest didn't respond.
> >>>
> >>>The approach taken by this commit is asynchronous and thus avoids
> >>>any QMP hangs.
> >>>
> >>>First, a client has to issue the balloon-get-memory-stats command.
> >>>That command gets the process started by only sending a request to
> >>>the guest, it doesn't block. When the memory stats are made available
> >>>by the guest, they are returned to the client as an QMP event.
> >>>
> >>>Signed-off-by: Luiz Capitulino<lcapitulino@redhat.com>
> >>
> >>Do we need this to be stable in 1.1?
> >>
> >>We can do this pretty nicely through QOM. We can have a polling
> >>property in the virtio-balloon driver, that when set, will enable
> >>the virtio-balloon device to poll the guest for statistics.
> >>
> >>We can also have properties for each of the memory statistics and a
> >>timestamp for when the last update was.
> >>
> >>I think this is a friendlier approach for clients, and a cleaner
> >>approach from a QEMU perspective.
> >>
> >>There's nothing generic about this functionality. It's extremely
> >>specific to virtio-balloon. We just lacked ways to expose device
> >>specific function pre-QOM.
> >
> >I'm not so sure, I think proxying guest agent commands through QMP
> >would hit very similar snags, for instance.
>
> We would proxy guest agent commands as asynchronous QMP commands, no?
Yup, that's the plan. Just mean that the balloon stats fall in the same
bucket and could (eventually) benefit from a more general solution. In
particular, with async QMP in place we could deprecate the polling approach
by having the request do basically what Luiz's patch does and calling
issuing the qmp completion instead of the event.
But I guess the more important question is getting the API right.
Something that allows us to basically turn query-balloon back on would
certainly be optimal... otherwise we'll add new QMP commands and deprecate
them fairly quickly. If avoiding that requires a polling mechanism then it
may be worth it in that sense.
I don't think that requires QOM though, just a stats_pending flags in
virtio-balloon and a periodic timer cb that sends a new request if it's
cleared. QOM might be nicer though.
>
> Regards,
>
> Anthony Liguori
>
> >
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>
> >
> >
>
next prev parent reply other threads:[~2012-02-17 21:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 20:30 [Qemu-devel] [PATCH 0/6] QMP: add balloon-get-memory-stats command Luiz Capitulino
2012-02-08 20:30 ` [Qemu-devel] [PATCH 1/6] balloon: qmp_balloon(): Use error_set() Luiz Capitulino
2012-02-08 20:30 ` [Qemu-devel] [PATCH 2/6] balloon: Drop unused include Luiz Capitulino
2012-02-08 20:30 ` [Qemu-devel] [PATCH 3/6] balloon: Rename QEMUBalloonStatus to QEMUBalloonInfo Luiz Capitulino
2012-02-08 20:30 ` [Qemu-devel] [PATCH 4/6] balloon: Refactor kvm sync mmu check Luiz Capitulino
2012-02-08 20:30 ` [Qemu-devel] [PATCH 5/6] balloon: Drop old stats interface Luiz Capitulino
2012-02-08 20:30 ` [Qemu-devel] [PATCH 6/6] qmp: add balloon-get-memory-stats & event Luiz Capitulino
2012-02-09 19:26 ` Adam Litke
2012-02-10 17:11 ` Luiz Capitulino
2012-02-17 16:55 ` Anthony Liguori
2012-02-17 17:09 ` Michael Roth
2012-02-17 20:07 ` Anthony Liguori
2012-02-17 21:38 ` Michael Roth [this message]
2012-02-17 17:16 ` Luiz Capitulino
2012-02-17 21:51 ` Michael Roth
2012-02-22 12:48 ` Luiz Capitulino
2012-02-22 15:05 ` Michael Roth
2012-02-22 16:09 ` Luiz Capitulino
2012-02-22 16:54 ` Michael Roth
2012-02-22 19:44 ` Luiz Capitulino
2012-02-22 20:27 ` Michael Roth
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=20120217213827.GD20920@illuin \
--to=mdroth@linux.vnet.ibm.com \
--cc=agl@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=lcapitulino@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).