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? Paolo -- 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
