From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWRXg-0008S9-8H for qemu-devel@nongnu.org; Mon, 21 May 2012 08:16:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWRXd-0002Ul-SD for qemu-devel@nongnu.org; Mon, 21 May 2012 08:16:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWRXd-0002UY-Kb for qemu-devel@nongnu.org; Mon, 21 May 2012 08:16:49 -0400 Date: Mon, 21 May 2012 17:46:42 +0530 From: Amit Shah Message-ID: <20120521121642.GC9725@amit.redhat.com> References: <1337163047-6159-1-git-send-email-berrange@redhat.com> <20120516154245.0d9b0cec@doriath.home> <4FB3F8DA.4030809@codemonkey.ws> <20120517074944.GB24943@redhat.com> <20120521111438.GA9725@amit.redhat.com> <20120521112952.GP24629@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120521112952.GP24629@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Add event notification for guest balloon changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Markus Armbruster , qemu-devel@nongnu.org, Anthony Liguori , Luiz Capitulino On (Mon) 21 May 2012 [12:29:52], Daniel P. Berrange wrote: > On Mon, May 21, 2012 at 04:44:38PM +0530, Amit Shah wrote: > > On (Thu) 17 May 2012 [08:49:44], Daniel P. Berrange wrote: > > > On Wed, May 16, 2012 at 01:58:34PM -0500, Anthony Liguori wrote: > > > > On 05/16/2012 01:42 PM, Luiz Capitulino wrote: > > > > >On Wed, 16 May 2012 11:10:47 +0100 > > > > >"Daniel P. Berrange" wrote: > > > > > > > > > >>From: "Daniel P. Berrange" > > > > >> > > > > >>After setting a balloon target value, applications have to > > > > >>continually poll 'query-balloon' to determine whether the > > > > >>guest has reacted to this request. The virtio-balloon backend > > > > >>knows exactly when the guest has reacted though, and thus it > > > > >>is possible to emit a JSON event to tell the mgmt application > > > > >>whenever the guest balloon changes. > > > > >> > > > > >>This introduces a new 'qemu_balloon_change()' API which is > > > > >>to be called by balloon driver backends, whenever they have > > > > >>a change in balloon value. This takes the 'actual' balloon > > > > >>value, as would be found in the BalloonInfo struct. > > > > >> > > > > >>The qemu_balloon_change API emits a JSON monitor event which > > > > >>looks like: > > > > >> > > > > >> {"timestamp": {"seconds": 1337162462, "microseconds": 814521}, > > > > >> "event": "BALLOON_CHANGE", "data": {"actual": 944766976}} > > > > > > > > > >It's missing an entry in QMP/qmp-events.txt and I have a comment below, > > > > >but in general looks good. > > > > > > > > > >Amit, would be good to get your ack. > > > > > > > > I think it would be safer to limit this event to (1) only firing > > > > once target has been reached (2) firing if target is deviated from > > > > without a corresponding change in target. > > > > > > > > Otherwise, a guest could just flood libvirt with events. This would > > > > queue memory in QEMU indefinitely as the events got queued up to > > > > potentially serving as a DoS against other guests. > > > > > > Hmm, that's a good point, but my concern was that if we only emit > > > the event when the target is reached, what happens if the guest > > > gets very close to the target but never actually reaches it for > > > some reason. > > > > > > Should we perhaps just rate limit it to once per second ? > > > > This also has a slight disadvantage of missing to send out a > > notification if it was received within the 1-second window, but no > > further events come from the guest. > > No, it would not (and indeed must not) miss any events. In the worst > case it would delay delivery of an event by upto 1 second, if an > identical event had already been sent within the last second. > > eg it would work as follows > > 1. First event arrives at time 250ms. Send it immediately > > 2. Second event arrives at time 300ms. Already had an event 50ms > ago. Do not send this event. Set 1 second timer. > > 3. Third event arrives at time 400ms. A timer is pending. Do not > send this event. Discard 2nd event. > > 4. Fourth event arrives at time 500ms. A timer is pending. Do not > send this event. Discard 3rd event. > > 5. Timer fires at time 1300ms. Send fourth event > > If the 5th event arrives before time 2300ms, we repeat the timer > delay process, otherwise we can send it immediately. > > So after every 1 second window we can *guarantee* that the app > has received the most recent event from that time window. (Yes, I just meant to note that such care should be taken.) > > Overall, the qmp emitter itself could gain a new API to rate-limit > > events, if so configured. > > Not all event types can be automatically rate-limited. Of course, I mentioned we need a new API for that. Amit