Re: [Qemu-devel] Re: KVM call agenda for Apr 27
Am 27.04.2010 00:36, schrieb Anthony Liguori: On 04/26/2010 05:12 PM, Chris Wright wrote: * Anthony Liguori (anth...@codemonkey.ws) 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). 2) A block plugin doesn't solve the problem if it's just at the BlockDriverState level because it can't interact with qcow2. There's no interaction with qcow2 needed, it would just need to remember the highest offset it was requested to read or write. But I'd really hate to stick another protocol between qcow2 and file. It doesn't solve the problem nicely though because it still needs to generate some event which is not present in a normal qemu without the plugin. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
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 (anth...@codemonkey.ws) 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 memory ballooning daemon we're developing basically does nothing but this. It monitors stats from the guest to generate events when we've reached a certain memory condition that will likely require some action (like ballooning). Why would we do the block watermarking in qemu and not do the ballooning heuristics too? I know of quite a few tools that all do some form of this. 2) A block plugin doesn't solve the problem if it's just at the BlockDriverState level because it can't interact with qcow2. There's no interaction with qcow2 needed, it would just need to remember the highest offset it was requested to read or write. But I'd really hate to stick another protocol between qcow2 and file. It doesn't solve the problem nicely though because it still needs to generate some event which is not present in a normal qemu without the plugin. Polling is really the right solution. It gives the management tool ultimate flexibility in tweaking the heuristics as they see fit. Regards, Anthony Liguori Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
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 (anth...@codemonkey.ws) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
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. Regards, Anthony Liguori Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
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. 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. 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? This is indeed a scenario where polling seems more natural. But in contrast, the watermark usually doesn't change most of the time and we want to know when changes happen. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
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. 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. This is indeed a scenario where polling seems more natural. But in contrast, the watermark usually doesn't change most of the time and we want to know when changes happen. Regards, Anthony Liguori Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
On 04/27/2010 08:58 AM, Kevin Wolf wrote: 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. But is statistic change really useful? During a guest install, you'd get hundreds and hundreds of these events. 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. It actually changes quite often early in it's lifetime. Regards, Anthony Liguori Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
On Mon, 26 Apr 2010 12:51:08 -0500 Anthony Liguori anth...@codemonkey.ws 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) What do you mean by push vs. pull? Anyway, Aurelien was working on a stable release last week, maybe he's interested in helping with the stables (or not :)). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call agenda for Apr 27
On Mon, Apr 26, 2010 at 10:15:58PM -0300, Luiz Capitulino wrote: On Mon, 26 Apr 2010 12:51:08 -0500 Anthony Liguori anth...@codemonkey.ws 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) What do you mean by push vs. pull? Anyway, Aurelien was working on a stable release last week, maybe he's interested in helping with the stables (or not :)). I didn't find the time to do the stable release, but we should be very close now. I am interested to have stable releases, but if someone else want to work on that, I am fine. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
