Am 27.04.2010 15:48, schrieb Anthony Liguori: > On 04/27/2010 08:42 AM, Kevin Wolf wrote: >> Am 27.04.2010 15:21, schrieb Anthony Liguori: >> >>> On 04/27/2010 08:18 AM, Kevin Wolf wrote: >>> >>>> 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? >>>> >>>> >>> Except then we need to offer a generic statistics mechanism which seems >>> like it's going to add a fair bit of complexity. So far, the only >>> argument for it seems to be a misplaced notion that "polling is evil". >>> >> I'm not sure if "adding events is evil" is a much better position. :-) >> >> The natural thing is really events here, because we want to get informed >> every time something changes. > > You want to be informed every time something has changed and the value > has met a boolean condition (value > threshold). > >> Polling is a workaround for cases where >> you can't get these events. So I think it's you who should explain why >> polling is so much better than using events. >> > > Polling gives a management tool more flexibility in implementing the > evaluation condition. > > Adding something to the protocol is a long term support statement. We > shouldn't add events unless we think they are events that we'll want to > support in the long term. If RHEV-M decides that instead of doing value > > threshold, they want to include additional information (maybe > factoring in I/O rate), then a new event needs to be added and we're > stuck supporting the old event forever. > > Polling lets us avoid introducing new protocol operations as heuristics > change. This is what I meant with the flexibility being orthogonal to polling vs. event-based. You're comparing apples and oranges. You can either compare sending an event when value > threshold with polling a boolean that says if this threshold is reached. Or you can compare sending an event on changes with polling the absolute value. But comparing sending an event on a threshold to polling the absolute value mixes two different things. >> Note that IIUC the case is here different from the ballooning you >> mentioned. The statistics for ballooning change all the time and you >> don't want to get informed about changes but monitor the statistics all >> the time, right? > > No, generally speaking, you care about threshold conditions. For > instance, you want to know when guest reported free memory is < some > percentage of total memory. It's very similar really. Hm, maybe implementing something generic with thresholds actually wouldn't be a bad idea then. But still you have the fact that it's changing all the time which is very different from the watermark. The watermark only ever grows and often doesn't change at all. So the watermark thing can live without thresholds, it's enough to get informed about any changes. 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
