Am 21.07.2010 21:18, schrieb Christian Brunner:
> 2010/7/20 Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx>:
>>> + 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
