From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIVYq-0007nX-9A for qemu-devel@nongnu.org; Thu, 30 Jun 2016 02:34:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIVYm-00027m-1q for qemu-devel@nongnu.org; Thu, 30 Jun 2016 02:34:51 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:40977 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIVYl-00027N-OB for qemu-devel@nongnu.org; Thu, 30 Jun 2016 02:34:47 -0400 References: <1467104499-27517-1-git-send-email-pl@kamp.de> <1467104499-27517-4-git-send-email-pl@kamp.de> <20160628105707.GG2243@work-vm> <57725CB0.7090606@kamp.de> <20160628113501.GH2243@work-vm> <577268DC.9080305@kamp.de> <20160628142007.GK2243@work-vm> From: Peter Lieven Message-ID: <5774BD7F.4050008@kamp.de> Date: Thu, 30 Jun 2016 08:34:39 +0200 MIME-Version: 1.0 In-Reply-To: <20160628142007.GK2243@work-vm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 03/15] coroutine-ucontext: reduce stack size to 64kB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Paolo Bonzini , qemu-devel@nongnu.org, kwolf@redhat.com, peter.maydell@linaro.org, mst@redhat.com, mreitz@redhat.com, kraxel@redhat.com Am 28.06.2016 um 16:20 schrieb Dr. David Alan Gilbert: > * Peter Lieven (pl@kamp.de) wrote: >> Am 28.06.2016 um 13:35 schrieb Dr. David Alan Gilbert: >>> * Peter Lieven (pl@kamp.de) wrote: >>>> Am 28.06.2016 um 12:57 schrieb Dr. David Alan Gilbert: >>>>> * Paolo Bonzini (pbonzini@redhat.com) wrote: >>>>>> On 28/06/2016 11:01, Peter Lieven wrote: >>>>>>> evaluation with the recently introduced maximum stack size monitoring revealed >>>>>>> that the actual used stack size was never above 4kB so allocating 1MB stack >>>>>>> for each coroutine is a lot of wasted memory. So reduce the stack size to >>>>>>> 64kB which should still give enough head room. >>>>>> If we make the stack this much smaller, there is a non-zero chance of >>>>>> smashing it. You must add a guard page if you do this (actually more >>>>>> than one because QEMU will happily have stack frames as big as 16 KB). >>>>>> The stack counts for RSS but it's not actually allocated memory, so why >>>>>> does it matter? >>>>> I think I'd be interested in seeing the /proc/.../smaps before and after this >>>>> change to see if anything is visible and if we can see the difference >>>>> in rss etc. >>>> Can you advise what in smaps should be especially looked at. >>>> >>>> As for RSS I can report hat the long term usage is significantly lower. >>>> I had the strange observation that when the VM is running for some minutes >>>> the RSS suddenly increases to the whole stack size. >>> You can see the Rss of each mapping; if you knew where your stacks were >>> it would be easy to see if it was the stacks that were Rss and if >>> there was anything else odd about them. >>> If you set hte mapping as growsdown then you can see the area that has a 'gd' >>> in it's VmFlags. >> Would you expect to see each 1MB allocation in smaps or is it possible that >> the kernel merges some mappings to bigger ones? >> >> And more importantly if the regions are merged Paolos comment about we >> do not need a guard page would not be true because a coroutine stack could >> grow into annother coroutines stack. Looking at the commit from Linus it >> would also be good to have that guard page not having the gd flag. > Hmm I'm not sure; one for Paolo. My fault. The second mmap call with the pointer to the stack must carry the MAP_FIXED flag. Peter