On Tue, Apr 27, 2010 at 02:11:46PM +0100, Daniel P. Berrange wrote: > On Tue, Apr 27, 2010 at 08:03:42AM -0500, Anthony Liguori wrote: > > On 04/27/2010 03:14 AM, Avi Kivity wrote: > > >On 04/27/2010 01:36 AM, Anthony Liguori wrote: > > >> > > >>A few comments: > > >> > > >>1) The problem was not block watermark itself but generating a > > >>notification on the watermark threshold. It's a heuristic and should > > >>be implemented based on polling block stats. > > > > > >Polling for an event that never happens is bad engineering. What > > >frequency do you poll? you're forcing the user to make a lose-lose > > >tradeoff. > > > > > >>Otherwise, we'll be adding tons of events to qemu that we'll struggle > > >>to maintain. > > > > > >That's not a valid reason to reject a user requirement. We may argue > > >the requirement is bogus, or that the suggested implementation is > > >wrong and point in a different direction, but saying that we may have > > >to add more code in the future due to other requirements is ... well I > > >can't find a word for it. > > > > Polling is the best solution because it offers the most flexibility. > > Baking the heuristic into qemu just removes flexibility for all consumers. > > Polling as the added advantage that you can recover better if the > app talking to QMP is offline for a period. eg if libvirt were > disconnected from QMP at the time the high watermark event were > triggered, the next you'll know is a ENOSPACE event. If the app > were able to poll on the allocation value, then it could immediately > see the watermark had been passed the first time it polled after > libvirt reconnected to QMP. As you say its also more flexible because > you can invent a usage where you have 2 or 3 watermarks where you > could try harder to get more space as you pass each watermark. > When libvirt reconnects it should poll once and then wait for notification. If you want to have several watermarks configure first one and after getting notification about it configure second one and so on. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
