From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy3Aw-00085E-U1 for qemu-devel@nongnu.org; Mon, 29 Aug 2011 10:51:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qy3Av-0000Y7-G0 for qemu-devel@nongnu.org; Mon, 29 Aug 2011 10:50:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy3Av-0000Xx-8C for qemu-devel@nongnu.org; Mon, 29 Aug 2011 10:50:57 -0400 From: Kevin Wolf Date: Mon, 29 Aug 2011 16:53:19 +0200 Message-Id: <1314629618-8308-12-git-send-email-kwolf@redhat.com> In-Reply-To: <1314629618-8308-1-git-send-email-kwolf@redhat.com> References: <1314629618-8308-1-git-send-email-kwolf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] [PATCH 11/30] posix-aio-compat: fix latency issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: anthony@codemonkey.ws Cc: kwolf@redhat.com, qemu-devel@nongnu.org From: Avi Kivity In certain circumstances, posix-aio-compat can incur a lot of latency: - threads are created by vcpu threads, so if vcpu affinity is set, aio threads inherit vcpu affinity. This can cause many aio threads to compete for one cpu. - we can create up to max_threads (64) aio threads in one go; since a pthread_create can take around 30=CE=BCs, we have up to 2ms of cpu tim= e under a global lock. Fix by: - moving thread creation to the main thread, so we inherit the main thread's affinity instead of the vcpu thread's affinity. - if a thread is currently being created, and we need to create yet another thread, let thread being born create the new thread, reducing the amount of time we spend under the main thread. - drop the local lock while creating a thread (we may still hold the global mutex, though) Note this doesn't eliminate latency completely; scheduler artifacts or lack of host cpu resources can still cause it. We may want pre-allocated threads when this cannot be tolerated. Thanks to Uli Obergfell of Red Hat for his excellent analysis and suggest= ions. Signed-off-by: Avi Kivity Signed-off-by: Kevin Wolf --- posix-aio-compat.c | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 42 insertions(+), 2 deletions(-) diff --git a/posix-aio-compat.c b/posix-aio-compat.c index babb094..3193dbf 100644 --- a/posix-aio-compat.c +++ b/posix-aio-compat.c @@ -30,6 +30,7 @@ =20 #include "block/raw-posix-aio.h" =20 +static void do_spawn_thread(void); =20 struct qemu_paiocb { BlockDriverAIOCB common; @@ -64,6 +65,9 @@ static pthread_attr_t attr; static int max_threads =3D 64; static int cur_threads =3D 0; static int idle_threads =3D 0; +static int new_threads =3D 0; /* backlog of threads we need to creat= e */ +static int pending_threads =3D 0; /* threads created but not running yet= */ +static QEMUBH *new_thread_bh; static QTAILQ_HEAD(, qemu_paiocb) request_list; =20 #ifdef CONFIG_PREADV @@ -311,6 +315,11 @@ static void *aio_thread(void *unused) =20 pid =3D getpid(); =20 + mutex_lock(&lock); + pending_threads--; + mutex_unlock(&lock); + do_spawn_thread(); + while (1) { struct qemu_paiocb *aiocb; ssize_t ret =3D 0; @@ -381,11 +390,20 @@ static void *aio_thread(void *unused) return NULL; } =20 -static void spawn_thread(void) +static void do_spawn_thread(void) { sigset_t set, oldset; =20 - cur_threads++; + mutex_lock(&lock); + if (!new_threads) { + mutex_unlock(&lock); + return; + } + + new_threads--; + pending_threads++; + + mutex_unlock(&lock); =20 /* block all signals */ if (sigfillset(&set)) die("sigfillset"); @@ -396,6 +414,27 @@ static void spawn_thread(void) if (sigprocmask(SIG_SETMASK, &oldset, NULL)) die("sigprocmask restor= e"); } =20 +static void spawn_thread_bh_fn(void *opaque) +{ + do_spawn_thread(); +} + +static void spawn_thread(void) +{ + cur_threads++; + new_threads++; + /* If there are threads being created, they will spawn new workers, = so + * we don't spend time creating many threads in a loop holding a mut= ex or + * starving the current vcpu. + * + * If there are no idle threads, ask the main thread to create one, = so we + * inherit the correct affinity instead of the vcpu affinity. + */ + if (!pending_threads) { + qemu_bh_schedule(new_thread_bh); + } +} + static void qemu_paio_submit(struct qemu_paiocb *aiocb) { aiocb->ret =3D -EINPROGRESS; @@ -665,6 +704,7 @@ int paio_init(void) die2(ret, "pthread_attr_setdetachstate"); =20 QTAILQ_INIT(&request_list); + new_thread_bh =3D qemu_bh_new(spawn_thread_bh_fn, NULL); =20 posix_aio_state =3D s; return 0; --=20 1.7.6