From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuKd1-0001YE-8s for qemu-devel@nongnu.org; Fri, 28 Nov 2014 07:26:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuKcs-0000Nb-4e for qemu-devel@nongnu.org; Fri, 28 Nov 2014 07:26:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuKcr-0000NR-TI for qemu-devel@nongnu.org; Fri, 28 Nov 2014 07:26:18 -0500 Message-ID: <547869DE.3080907@redhat.com> Date: Fri, 28 Nov 2014 13:26:06 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1417084026-12307-1-git-send-email-pl@kamp.de> <1417084026-12307-4-git-send-email-pl@kamp.de> <547753F7.2030709@redhat.com> <54782EC3.10005@kamp.de> <54784E55.6060405@redhat.com> <54785067.60905@kamp.de> <547858FF.5070602@redhat.com> <54785AA5.9070409@kamp.de> <54785B2E.9070203@redhat.com> <54785D60.1070306@kamp.de> <5478609B.8060503@kamp.de> In-Reply-To: <5478609B.8060503@kamp.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 3/3] qemu-coroutine: use a ring per thread for the pool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , ming.lei@canonical.com, Kevin Wolf , Stefan Hajnoczi , "qemu-devel@nongnu.org" , Markus Armbruster On 28/11/2014 12:46, Peter Lieven wrote: > > I get: > > Run operation 40000000 iterations 9.883958 s, 4046K operations/s, 247ns per coroutine > > Ok, understood, it "steals" the whole pool, right? Isn't that bad if we have more > than one thread in need of a lot of coroutines? Overall the algorithm is expected to adapt. The N threads contribute to the global release pool, so the pool will fill up N times faster than if you had only one thread. There can be some variance, which is why the maximum size of the pool is twice the threshold (and probably could be tuned better). Benchmarks are needed on real I/O too, of course, especially with high queue depth. Paolo