From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] kvm tools: Process virito blk requests in separate thread Date: Wed, 06 Jun 2012 14:35:28 +0200 Message-ID: <4FCF4E90.7050806@redhat.com> References: <1338824453-25260-1-git-send-email-asias.hejun@gmail.com> <1338826065.3292.10.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Asias He , Pekka Enberg , Ingo Molnar , Cyrill Gorcunov , kvm@vger.kernel.org To: Sasha Levin Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:57285 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752106Ab2FFMfd (ORCPT ); Wed, 6 Jun 2012 08:35:33 -0400 Received: by dady13 with SMTP id y13so8736130dad.19 for ; Wed, 06 Jun 2012 05:35:33 -0700 (PDT) In-Reply-To: <1338826065.3292.10.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: 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