Tarantool development patches archive
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@freelists.org, vdavydov.dev@gmail.com,
	kostja@tarantool.org
Subject: Re: [tarantool-patches] [PATCH 1/3] core/fiber: Increase default stack size
Date: Wed, 6 Mar 2019 10:09:43 +0300	[thread overview]
Message-ID: <20190306070943.GA10420@uranus.lan> (raw)
In-Reply-To: <20190305234336.rwffevewm4ooqun3@tkn_work_nb>

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.

  reply	other threads:[~2019-03-06  7:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 22:38 [PATCH v3 0/3] core/fiber: Rework stack management Cyrill Gorcunov
2019-03-05 22:38 ` [PATCH 1/3] core/fiber: Increase default stack size Cyrill Gorcunov
2019-03-05 23:43   ` [tarantool-patches] " Alexander Turenko
2019-03-06  7:09     ` Cyrill Gorcunov [this message]
2019-03-06  7:30     ` Konstantin Osipov
2019-03-05 22:38 ` [PATCH 2/3] core/fiber: Mark stack as unneeded on creation Cyrill Gorcunov
2019-03-05 22:38 ` [PATCH 3/3] core/fiber: Put watermarks into stack to track its usage Cyrill Gorcunov
2019-03-06 18:05   ` Vladimir Davydov
2019-03-06 19:03     ` Cyrill Gorcunov
2019-03-07  8:27       ` Vladimir Davydov
2019-03-07  9:04         ` Cyrill Gorcunov
2019-03-07  9:20           ` Vladimir Davydov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190306070943.GA10420@uranus.lan \
    --to=gorcunov@gmail.com \
    --cc=alexander.turenko@tarantool.org \
    --cc=kostja@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=vdavydov.dev@gmail.com \
    --subject='Re: [tarantool-patches] [PATCH 1/3] core/fiber: Increase default stack size' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox