[tarantool-patches] [PATCH 1/3] core/fiber: Increase default stack size

[Cyrill Gorcunov]

On Wed, Mar 06, 2019 at 02:43:37AM +0300, Alexander Turenko wrote:
...
> > diff --git a/src/lib/core/fiber.c b/src/lib/core/fiber.c
> > index abd6c6b11..d4d16c05e 100644
> > --- a/src/lib/core/fiber.c
> > +++ b/src/lib/core/fiber.c
> > @@ -92,10 +92,10 @@ static size_t page_size;
> >  static int stack_direction;
> >  
> >  enum {
> > -	/* The minimum allowable fiber stack size in bytes */
> > -	FIBER_STACK_SIZE_MINIMAL = 16384,
> > -	/* Default fiber stack size in bytes */
> > -	FIBER_STACK_SIZE_DEFAULT = 65536
> > +	/* The minimum allowable fiber stack size in 4K page */
> > +	FIBER_STACK_SIZE_MINIMAL = 4 << 12,
> > +	/* Default fiber stack size in 4K page */
> > +	FIBER_STACK_SIZE_DEFAULT = 64 << 12,
> 
> I recently looked at #3564 and observed that 256 KiB of stack is not
> enough for our http client (the wrapper around libcurl). I bisected how
> much it requeres and found that it fails with 448 KiB, but succeeds with
> 480 KiB. I just tried the following case with different
> FIBER_STACK_SIZE_DEFAULT constants on our tt-mac machine:
> 
> ./src/tarantool <<< "print(require('json').encode(require('http.client').get('http://google.com')))"
> 
> Tarantool is linked to libcurl-7.61.0:
> 
> $ otool -L ./src/tarantool | grep libcurl
> 	/usr/local/opt/curl/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
> $ strings /usr/local/opt/curl/lib/libcurl.4.dylib | grep libcurl/
> libcurl/7.61.0

You know, I think this run and catch game will continue forever,
because we simply don't know in which environment users will
run tarantool. As being discussed with Vladimir we must provide
a way to a user to configure stack size. Most probably via
environment variable. I simply didn't implement it yet.

Also initially we started with 1M stack but then desided to
shrink back to 256K. Looks like 512K would suffice all sides.

> However this case succeeds on my Linux machine on tarantool with 64 KiB
> stack with libcurl-7.63.0. Don't sure what is matter: libcurl version,
> OS, some compilation or runtime options of libcurl. But at least we see
> that there are environments where 256 KiB is not enough.
> 
> Maybe we should investigate what lead libcurl to use so much stack size
> in that environment and possibly will find a way to configure it (at
> runtime) to avoid this. Don't sure. So this message is just for the
> record.
> 
> https://github.com/tarantool/tarantool/issues/3564

libcurl and etc are third party libs which we don't control so
we of course could investigate but only once time permit.