Am 27.04.2010 15:10, schrieb Anthony Liguori: > On 04/27/2010 03:53 AM, Kevin Wolf wrote: >> Am 27.04.2010 00:36, schrieb Anthony Liguori: >> >>> On 04/26/2010 05:12 PM, Chris Wright wrote: >>> >>>> * Anthony Liguori (anthony@xxxxxxxxxxxxx) wrote: >>>> >>>> >>>>> On 04/26/2010 12:26 PM, Chris Wright wrote: >>>>> >>>>> >>>>>> Please send in any agenda items you are interested in covering. >>>>>> >>>>>> While I don't expect it to be the case this week, if we have a >>>>>> lack of agenda items I'll cancel the week's call. >>>>>> >>>>>> >>>>> - qemu management interface (and libvirt) >>>>> - stable tree policy (push vs. pull and call for stable volunteers) >>>>> >>>>> >>>> block plug in (follow-on from qmp block watermark) >>>> >>>> >>> 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. Otherwise, we'll be adding >>> tons of events to qemu that we'll struggle to maintain. >>> >> Polling just feels completely wrong. You're almost guaranteed to poll in >> the wrong intervals because depending on what the guest is doing you >> might need it every couple of seconds (installation) or you may not need >> it in days (just working on a fully allocated image). >> > > The event basically boils down to: when some threshold is reached, raise > an event. What statistics go into this computation and what algorithm > is used to compute the threshold depends on the management tool. The watermark is not some complex computed value, but actually the statistic itself. We can get rid of handling a threshold in qemu by just signalling "something has changed with this stat". I'm really not arguing that qemu should do anything complex or even define policy. It's just about avoiding polling all the time when nothing has changed and polling too late when things are changing quickly. > Polling is really the right solution. It gives the management tool > ultimate flexibility in tweaking the heuristics as they see fit. Isn't providing this flexibility completely orthogonal to polling vs. event-based? Kevin -- 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
