Hollis Blanchard wrote:
On Wed, 2009-04-08 at 16:14 -0500, Anthony Liguori wrote:
It has to be some finite amount. You're right, it's arbitrary, but so
is every other memory limitation we have in QEMU. You could make it
user configurable but that's just punting the problem.
You have to do some level of buffering. It's unavoidable. If you
aren't buffering at the event level, you buffer at the socket level, etc.
If the socket will buffer it, why do you *also* want to buffer in qemu
(adding code and complexity)?
If you fill the socket buffer, you have two choices. You can sleep,
which is unacceptable in QEMU since we're single threaded, or you can
drop data. If you drop data in something like the monitor, it will lead
to corruption which is unrecoverable for a management tool.
You have to push that information higher up the stack so that the thing
pushing data can make more intelligent decisions about what to drop. In
this case, we're dropping anything older than 10 minutes. We'll
probably need an max-number of events too but right now, it's based on time.
Regards,
Anthony Liguori
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list