From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHqYE-0006xT-6r for qemu-devel@nongnu.org; Tue, 28 Jun 2016 06:47:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHqYA-0002pf-2B for qemu-devel@nongnu.org; Tue, 28 Jun 2016 06:47:29 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:57424 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHqY9-0002pM-OT for qemu-devel@nongnu.org; Tue, 28 Jun 2016 06:47:25 -0400 References: <1467104499-27517-1-git-send-email-pl@kamp.de> <1467104499-27517-5-git-send-email-pl@kamp.de> <7b4e4b2d-0de4-148f-6213-648611137771@redhat.com> From: Peter Lieven Message-ID: <577255B7.9000704@kamp.de> Date: Tue, 28 Jun 2016 12:47:19 +0200 MIME-Version: 1.0 In-Reply-To: <7b4e4b2d-0de4-148f-6213-648611137771@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/15] coroutine: add a knob to disable the shared release pool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, mst@redhat.com, dgilbert@redhat.com, mreitz@redhat.com, kraxel@redhat.com Am 28.06.2016 um 12:41 schrieb Paolo Bonzini: > > On 28/06/2016 11:01, Peter Lieven wrote: >> the current coroutine freelist implementation has 2 kinds of pools. >> One shared release pool between all threads and additionally one >> allocation pool per thread. The release pool is especially necessary >> if the coroutine is created in a different thread than it is released. >> This is e.g. the case if an IDE interface is used. >> >> But in times of virtio and dataplane the the release pool adds costs >> which are not entirely necessary. At first if virtio is used the release >> pool tends to fill up to 100% because all coroutines are first handed >> back to the release pool. On coroutine create a thread can steal this >> release pool and make it its local allocation pool, but during mixed >> I/O pattern at the end the release pool is full of useless coroutines >> and the alloc_pool has also filled to maximum size. > The cost is 2^16 bytes * 2^6 coroutines, that is 4 MB. I don't think > this is worth an extra knob that no one will use... You are right, I was having this patch prior to reducing the stack size. In fact its 2 * 2^6 coroutines. But maybe its worth of thinking making the release_pool the same max size as the alloc_pool? Otherwise when the release_pool is stolen it could make the alloc_pool also that big. Peter