----- Original Message ----- > From: "Peter Lieven" <[email protected]> > To: "Paolo Bonzini" <[email protected]>, [email protected] > Cc: [email protected], "peter maydell" <[email protected]>, > [email protected], [email protected], > [email protected], [email protected] > 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
