On 05/16/2013 09:17 AM, Michael S. Tsirkin wrote:

>> The
>> existing throttling approach ensures that if the event includes latest
>> guest information, then the host doesn't even have to do do a query, and
>> is guaranteed that reacting to the final event will always see the most
>> recent request.  But most importantly, if the existing throttling works,
>> why do we have to invent a one-off approach for this event instead of
>> reusing existing code?
> 
> Because of the 1st issue above. A large delay because we
> exceed an arbitrary throttling rate would be bad
> for the guest. Contrast with delay in e.g.
> device delete event.
> The throttling mechanism is good for events that host cares
> about, not for events that guest cares about.

Alright, your argument has me convinced :)  Looks like we DO want to
react to the guest as fast as possible, for less missed traffic in the
guest, but also without overwhelming the host with events.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org