Re: [Qemu-devel] [PATCH 03/15] coroutine-ucontext: reduce stack size to 64kB

[Paolo Bonzini]

----- Original Message -----
> From: "Peter Lieven" <address@hidden>
> To: "Paolo Bonzini" <address@hidden>, address@hidden
> Cc: address@hidden, "peter maydell" <address@hidden>, address@hidden, 
> address@hidden,
> address@hidden, address@hidden
> Sent: Tuesday, June 28, 2016 1:13:26 PM
> Subject: Re: [PATCH 03/15] coroutine-ucontext: reduce stack size to 64kB
> 
> Am 28.06.2016 um 12:54 schrieb Paolo Bonzini:
> >
> > 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?
> 
> Is there an easy way to determinate how much of the RSS is actually
> allocated? I erroneously it was all allocated....
> 
> So as for the stack, the MAP_GROWSDOWN is it really important? Will the
> kernel
> allocate all pages of the stack otherwise if the last page is written?
> 
> I am asking because I don't know if MAP_GROWSDOWN is a good idea as Peter
> mentioned there were discussions to deprecate it.

I don't know, I found those discussions too.  However I've also seen
an interesting patch to ensure a guard page is kept at the bottom of the
VMA.

But thinking more about it, if you use MAP_GROWSDOWN you don't know anymore
where the bottom of the stack and you cannot free it correctly, can you?
Or am I completely misunderstanding the purpose of the flag?

I guess it's better to steer clear of it unless we're ready to look at
kernel code for a while...

Paolo