From: Cyrill Gorcunov <gorcunov@gmail.com> To: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: "Георгий Кириченко" <georgy@tarantool.org>, tarantool-patches@freelists.org Subject: Re: [RFC v3] fiber: Increase default stack size Date: Tue, 26 Feb 2019 12:12:54 +0300 [thread overview] Message-ID: <20190226091254.GL7198@uranus> (raw) In-Reply-To: <20190226085852.ugkqo6dz5nmjbhze@esperanza> On Tue, Feb 26, 2019 at 11:58:52AM +0300, Vladimir Davydov wrote: ... > > > > 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 OK > > 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. Will continue at the evening. Also note that stack is special and we better should not pass arbitrary sizes to allocate even for custom stacks, they all _must_ be PAGE_SIZE aligned (or call it PAGE_SIZE orders if you prefer :) Anything else make madvise idea useless since kernel requires madvise args to be page aligned which is understandable due to hardware. > > > > 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. OK
next prev parent reply other threads:[~2019-02-26 9:12 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-22 20:16 [tarantool-patches] [RFC v2] " Cyrill Gorcunov 2019-02-25 14:55 ` Vladimir Davydov 2019-02-25 15:25 ` Cyrill Gorcunov 2019-02-25 21:39 ` [RFC v3] " Cyrill Gorcunov 2019-02-26 8:58 ` Vladimir Davydov 2019-02-26 9:12 ` Cyrill Gorcunov [this message] 2019-02-26 10:26 ` Vladimir Davydov 2019-02-26 10:36 ` Vladimir Davydov 2019-02-26 11:17 ` Cyrill Gorcunov 2019-02-26 12:25 ` Vladimir Davydov 2019-02-26 11:16 ` Cyrill Gorcunov 2019-02-26 12:34 ` Vladimir Davydov 2019-02-26 12:54 ` Cyrill Gorcunov 2019-02-26 13:06 ` Vladimir Davydov 2019-02-26 13:26 ` [tarantool-patches] " Konstantin Osipov 2019-02-26 14:02 ` Cyrill Gorcunov 2019-02-26 10:32 ` Vladimir Davydov 2019-02-26 11:18 ` Cyrill Gorcunov
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=20190226091254.GL7198@uranus \ --to=gorcunov@gmail.com \ --cc=georgy@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=vdavydov.dev@gmail.com \ --subject='Re: [RFC v3] 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