On Fri, 23 Jul 2010, Kevin Wolf wrote:
> 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?
In theory, small requests can, yes. We haven't seen it in practice, I
don't think.
In any case, I think any waiting/throttling just needs to happen inside
the librados library, as that is the only place that may have any
knowledge of the cluster size, throughput, and so forth. This code should
be dropped from the qemu-kvm/rbd side.
sage
--
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
