Am 21.07.2010 21:18, schrieb Christian Brunner: > 2010/7/20 Yehuda Sadeh Weinraub <[email protected]>: >>> + while (s->queuesize > MAX_QUEUE_SIZE) { >>> + qemu_mutex_lock(s->queue_mutex); >>> + qemu_cond_wait(s->queue_threshold, s->queue_mutex); >>> + qemu_mutex_unlock(s->queue_mutex); >>> + } >> >> Actually we shouldn't be waiting inside the aio handler. We should >> probably be feeding the request into some wait queue and have a >> separate thread that drains all those requests out. Though this >> wouldn't help us in throttling the client memory, it's probably a more >> correct way to handle the problem. > > I agree with you, however I don't think that this is worth the effort. > I've never seen this occur when running a virtual machine, only when > running qemu-io. > > @Kevin: Did you follow this thread? What is your opinion?
No, I'm not subscribed to your mailing list and qemu-devel isn't CCed. I'm not entirely sure what kind of queue this is about, but are you sure that it can only happen with large requests as issued by qemu-io? Can many small requests cause the same, especially with a slow network connection (or it might even go down for some reason? If I understand correctly, waiting here could cause qemu to become unresponsive, right? Kevin -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
