From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvY9c-00066Q-Uz for qemu-devel@nongnu.org; Mon, 22 Aug 2011 13:19:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvY9b-0004WJ-Qn for qemu-devel@nongnu.org; Mon, 22 Aug 2011 13:19:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvY9b-0004Vd-Ji for qemu-devel@nongnu.org; Mon, 22 Aug 2011 13:19:15 -0400 Message-ID: <4E52903E.7040909@redhat.com> Date: Mon, 22 Aug 2011 19:22:06 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1313294689-21572-1-git-send-email-avi@redhat.com> In-Reply-To: <1313294689-21572-1-git-send-email-avi@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] posix-aio-compat: fix latency issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org Am 14.08.2011 06:04, schrieb 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 t= ime > under a global lock. >=20 > 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, reducin= g > 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) >=20 > Note this doesn't eliminate latency completely; scheduler artifacts or > lack of host cpu resources can still cause it. We may want pre-allocat= ed > threads when this cannot be tolerated. >=20 > Thanks to Uli Obergfell of Red Hat for his excellent analysis and sugge= stions. >=20 > Signed-off-by: Avi Kivity > --- > v2: simplify do_spawn_thread() locking Thanks, applied to the block branch. Kevin