On Wed, Jun 6, 2012 at 8:35 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Il 04/06/2012 18:07, Sasha Levin ha scritto: >>> > All blk requests are processed in notify_vq() which is in the context of >>> > ioeventfd thread: ioeventfd__thread(). The processing in notify_vq() may >>> > take a long time to complete and all devices share the single ioeventfd >>> > thead, so this might block other device's notify_vq() being called and >>> > starve other devices. >> We're using native vectored AIO for for processing blk requests, so I'm >> not certain if theres any point in giving the blk device it's own thread >> for handling that. > > I never looked at the kvmtool code, but I think Asias has a point. If > the guest submits I/O to lots of devices, they would contend on the > single thread. There was a similar proof of concept patch for QEMU that > provided substantial benefit. > > However, it sounds a bit wasteful to have the dedicated thread run with > a second eventfd. Would it be hard to just use the virtio-blk ioeventfd > directly? Without this patch, we are already using the virtio-blk ioeventfd which is being monitored in the shared ioeventfd__thread() thead. The eventfd in this patch is being used as a way to decouple the processing work from the ioeventfd__thread() thead. It's a bit like pthread_cond_signal()/pthread_cond_wait(). -- Asias He -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
