From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHr0y-0007B9-Gk for qemu-devel@nongnu.org; Tue, 28 Jun 2016 07:17:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHr0u-0001Cx-Ee for qemu-devel@nongnu.org; Tue, 28 Jun 2016 07:17:12 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:54742 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHr0u-0001Cl-4q for qemu-devel@nongnu.org; Tue, 28 Jun 2016 07:17:08 -0400 References: <1467104499-27517-1-git-send-email-pl@kamp.de> <1467104499-27517-4-git-send-email-pl@kamp.de> <20160628105707.GG2243@work-vm> From: Peter Lieven Message-ID: <57725CB0.7090606@kamp.de> Date: Tue, 28 Jun 2016 13:17:04 +0200 MIME-Version: 1.0 In-Reply-To: <20160628105707.GG2243@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" , Paolo Bonzini Cc: 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 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. Peter