[RFC v3] fiber: Increase default stack size

[Vladimir Davydov]

On Tue, Feb 26, 2019 at 12:39:55AM +0300, Cyrill Gorcunov wrote:
> The default 64K stack size used for years become too
> small for modern distors (Fedora 29 and etc) where third
> party libraries (such as ncurses) started to use 64K for
> own buffers and we get SIGSGV early without reaching
> interactive console phase.
> 
> To address this problem and hopefully eliminate such
> problems in future we increase default size up to 1M.
> Because this value may be too big for old distros or
> other libraries, which would never use such deep stack,
> we do a trick: put watermark at 64K offset of the stack
> and once fiber get recycled we try to relax memory
> pressue with madvise syscall.
> 
> https://github.com/tarantool/tarantool/issues/3418

Forgot to tell you during the previous review round: we don't put a full
link in the commit message. Instead we write:

Closes #3418

We put the link after the diff separator (---) so as a reviewer can
easily open it.

> ---
> Vladimir, take a look please. That is what you mean?

Yes.

> I'm not yet familiar with slab engine, does it allocates
> pages on lazy fashion or we need to pass 'dontneed' on
> first fiber creation too?

Oops, you're right, good catch! The allocator may poison slab if NDEBUG
is unset. So we can either

 - Madvise slab on fiber creation, at least in NDEBUG mode. Simple, but
   depends on the allocator internals.
 - Patch the 'small' library to make the allocator do madvise for us.
   IMO it would look better, but would clutter the allocator API.
 - Don't use 'small' allocator at all for default slab allocations, and
   simply mmap stack and link them in a free list (is it OK to mmap a
   few MB chunk per each fiber?).

I'm inclined to choose the last option. I'll discuss the options with
others today and follow-up.

> 
> And please re-check stack/mark position calculus once again,
> brain is off already I might miss something obvious.

I will, sure.

> 
> Also should not we give user a way to configure this early
> params, maybe via getenv?

May be, but this can definitely be done later if we really need it.