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 714F4279CB for ; Fri, 22 Feb 2019 02:46:11 -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 8vXQ16l4ekou for ; Fri, 22 Feb 2019 02:46:11 -0500 (EST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 09B8426233 for ; Fri, 22 Feb 2019 02:46:10 -0500 (EST) Received: by mail-lj1-f178.google.com with SMTP id z7so740971lji.0 for ; Thu, 21 Feb 2019 23:46:10 -0800 (PST) Date: Fri, 22 Feb 2019 10:46:07 +0300 From: Cyrill Gorcunov Subject: [tarantool-patches] Re: [RFC] fiber: Increase default stack size Message-ID: <20190222074607.GU7198@uranus> References: <20190221212642.GT7198@uranus> <7936473.6eviP72C8M@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7936473.6eviP72C8M@home.lan> 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: =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= Cc: tarantool-patches@freelists.org On Fri, Feb 22, 2019 at 10:38:42AM +0300, Георгий Кириченко wrote: > Hi Cyrill! Hi! > Thanks for the patch, please see some comments bellow. > I like your approach but I think we should do it in a different manner: we > could poison 64k page of a fiber stack on start and then check the poison mark > when fiber finished. If watermark was overwritten by fiber activity we could use > madvise in order to decrease RSS usage. I somehow fail to see how it is different from the current scheme. In the patch we put single 8 16 bytes poison at 64K (well, page aligned offset to be precise) and once the fiber scheduled out we test it. I suspect the difference you mean is to _when_ test the poison? Or you mean to poison the whole 64K? p.s. You know, I think this stack limits *must not* be fixed in size but rather configurable from some parameters (getenv or something). Otherwise it will be an endless run and catch game.