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 CBA1928141 for ; Fri, 22 Feb 2019 04:45:33 -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 I6fEwFFsZNfO for ; Fri, 22 Feb 2019 04:45:33 -0500 (EST) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (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 62DC028040 for ; Fri, 22 Feb 2019 04:45:33 -0500 (EST) Received: by mail-lf1-f68.google.com with SMTP id n15so1243337lfe.5 for ; Fri, 22 Feb 2019 01:45:33 -0800 (PST) Date: Fri, 22 Feb 2019 12:45:28 +0300 From: Cyrill Gorcunov Subject: [tarantool-patches] Re: [RFC] fiber: Increase default stack size Message-ID: <20190222094528.GV7198@uranus> References: <20190221212642.GT7198@uranus> <7936473.6eviP72C8M@home.lan> <20190222074607.GU7198@uranus> <1732287.KUceHh0FeD@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1732287.KUceHh0FeD@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 12:24:12PM +0300, Георгий Кириченко wrote: > > > > 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? > > I complain only that you check poison on each fiber schedule what could be too > expensive - a fiber could be scheduled about million times per second. > I think If we would check a fiber stack poison when it goes to recycle so is > will be a better option. Sounds reasonable. Will take a look, thanks! Still we should take into account that the stack of a fiber (for our regular fibers) won't exceed 1M thus will be covered by 2M pmd entry and expensive part is a cache line refill only. Initially I thought if I could simply test for poison just once when fiber is sched'ing out but then realised that a task can easily wipe poison out on later sched cycles.