From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BBEE327CED for ; Tue, 26 Feb 2019 08:26:34 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-sZaUcXHoQB for ; Tue, 26 Feb 2019 08:26:34 -0500 (EST) Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 671D120862 for ; Tue, 26 Feb 2019 08:26:34 -0500 (EST) Date: Tue, 26 Feb 2019 16:26:31 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [RFC v3] fiber: Increase default stack size Message-ID: <20190226132631.GA21937@chai> References: <20190222201639.GA7198@uranus> <20190225145516.6fdmob3tdkft5sky@esperanza> <20190225213955.GI7198@uranus> <20190226085852.ugkqo6dz5nmjbhze@esperanza> <20190226091254.GL7198@uranus> <20190226102656.gwwy35jyaqdkci3l@esperanza> <20190226111632.GM7198@uranus> <20190226123456.k66j25qv57vygm6u@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190226123456.k66j25qv57vygm6u@esperanza> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: Cyrill Gorcunov , =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= * Vladimir Davydov [19/02/26 15:37]: > > Hmm, why? Consider the example with PATH_MAX buffer. Putting dirty marks > at page boundaries doesn't guarantee any of them will get overwritten by > the buffer if only a few hundred of bytes are used. I think we should > dirty the last page or two at random intervals - this should increase > the chance that at least one mark is overwritten by any function that is > eager for the stack. More importantly, since stack usage/layout is usually the same in all fibers, i.e. it depends only on particular invocation chain, and random markers could be set at different locations at different fibers we are almost guaranteed to spot the problem sooner or later, moreover, more likely sooner than later. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov