From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGNo5-0000y2-S1 for qemu-devel@nongnu.org; Fri, 24 Jun 2016 05:53:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGNo1-0003Rb-UE for qemu-devel@nongnu.org; Fri, 24 Jun 2016 05:53:49 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:36200 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGNo1-0003RB-KR for qemu-devel@nongnu.org; Fri, 24 Jun 2016 05:53:45 -0400 Message-ID: <576D0325.1020002@kamp.de> Date: Fri, 24 Jun 2016 11:53:41 +0200 From: Peter Lieven MIME-Version: 1.0 References: <5768F923.7040502@kamp.de> <20160621131815.GB2264@work-vm> <57695979.2020102@kamp.de> <20160622105656.GC11330@stefanha-x1.localdomain> <576AED47.4010504@kamp.de> <20160624093724.GC9558@stefanha-x1.localdomain> In-Reply-To: <20160624093724.GC9558@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Qemu and heavily increased RSS usage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Peter Maydell Cc: Paolo Bonzini , "Dr. David Alan Gilbert" , "qemu-devel@nongnu.org" Am 24.06.2016 um 11:37 schrieb Stefan Hajnoczi: > On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote: >> On 22 June 2016 at 20:55, Peter Lieven wrote: >>> What makes the coroutine pool memory intensive is the stack size of 1MB per >>> coroutine. Is it really necessary to have such a big stack? >> That reminds me that I was wondering if we should allocate >> our coroutine stacks with MAP_GROWSDOWN (though if we're >> not actually using 1MB of stack then it's only going to >> be eating virtual memory, not necessarily real memory.) > Yes, MAP_GROWSDOWN will not reduce RSS. Yes, I can confirm just tested... > > It's possible that we can reduce RSS usage of the coroutine pool but it > will require someone to profile the pool usage patterns. It would be interesting to see what stack size we really need. Is it possible to automatically detect this value (at compile time?) I can also confirm that the coroutine pool is the second major RSS user beside heap fragmentation. Lowering the mmap threshold of malloc to about 32k also gives good results. In this case there are very few active mappings in the running vServer, but the RSS is still at about 50MB (without coroutine pool). Maybe it would be good to identify which parts of Qemu malloc lets say >16kB and convert them to mmap if it is feasible. Peter