From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 26 Feb 2019 11:58:52 +0300 From: Vladimir Davydov Subject: Re: [RFC v3] fiber: Increase default stack size Message-ID: <20190226085852.ugkqo6dz5nmjbhze@esperanza> References: <20190222201639.GA7198@uranus> <20190225145516.6fdmob3tdkft5sky@esperanza> <20190225213955.GI7198@uranus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190225213955.GI7198@uranus> To: Cyrill Gorcunov Cc: =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= , tarantool-patches@freelists.org List-ID: 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.