From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0InD-0003Ub-H6 for qemu-devel@nongnu.org; Wed, 22 Feb 2012 15:28:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0InC-0005jh-9A for qemu-devel@nongnu.org; Wed, 22 Feb 2012 15:28:03 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:45049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0InB-0005jU-UL for qemu-devel@nongnu.org; Wed, 22 Feb 2012 15:28:02 -0500 Received: by pbbro12 with SMTP id ro12so664682pbb.4 for ; Wed, 22 Feb 2012 12:28:00 -0800 (PST) Sender: fluxion Date: Wed, 22 Feb 2012 14:27:55 -0600 From: Michael Roth Message-ID: <20120222202755.GC2824@illuin> References: <1328733040-16697-1-git-send-email-lcapitulino@redhat.com> <1328733040-16697-7-git-send-email-lcapitulino@redhat.com> <4F3E868D.8020107@us.ibm.com> <20120217151622.682d307b@doriath.home> <20120217215133.GE20920@illuin> <20120222104813.650f7779@doriath.home> <20120222150522.GA2824@illuin> <20120222140935.7a01acda@doriath.home> <20120222165445.GB2824@illuin> <20120222174437.3626fafe@doriath.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120222174437.3626fafe@doriath.home> Subject: Re: [Qemu-devel] [PATCH 6/6] qmp: add balloon-get-memory-stats & event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: armbru@redhat.com, Anthony Liguori , eblake@redhat.com, qemu-devel@nongnu.org, agl@us.ibm.com On Wed, Feb 22, 2012 at 05:44:37PM -0200, Luiz Capitulino wrote: > On Wed, 22 Feb 2012 10:54:45 -0600 > Michael Roth wrote: > > > But I'm not suggesting we make query-balloon asynchronous. > > > > I'm suggesting be re-enable it as a synchronous interface by having it > > immediately return the latest-available results from a timer-driven > > query mechanism that tucks away the query results, such as the one Anthony > > suggested. > > I'm not sure I like the semantics, as query-balloon would have some fields > that actually depends on a timer based polling being enabled somewhere else, > while others fields ('actual') would always be there. I think that's more a side-effect of sticking stats unrelated to ballooning in query-balloon in the first place... but yah, maybe it makes the interfaces not worth reviving. > > > > But that's a dead discussion I guess, as I already agreed on implementing > > > this as a device property. > > > > Along with timer-based refresh of the properties? If so I don't understand why we > > can't just have query-balloon simply return those properties when it's called? I > > thought that's what Anthony was driving at with the timer-based > > approach. > > What I had understood is to make each stats a dynamic device property, then > mngt apps would use qom-set/get on them. Ahhhh, yah... you're probably right. And we get that for free by tieing the data to properties, which I guess is where the significance of QOM was wrt to the polling approach (since we could actually stick the data anywhere if we did something like query-balloon). I don't really have any objection there, my main concern was that we were gonna be adding something *beyond* qom-get or query-balloon, but if that's not the case, carry on :) > > Anthony, can you detail your suggestion please? >