From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Thu, 7 Mar 2019 12:04:39 +0300 From: Cyrill Gorcunov Subject: Re: [PATCH 3/3] core/fiber: Put watermarks into stack to track its usage Message-ID: <20190307090439.GE10420@uranus.lan> References: <20190305223854.14660-1-gorcunov@gmail.com> <20190305223854.14660-4-gorcunov@gmail.com> <20190306180504.dsa4xq6kbdbymgqe@esperanza> <20190306190349.GD10420@uranus.lan> <20190307082758.qywkiey7y5hudcpv@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190307082758.qywkiey7y5hudcpv@esperanza> To: Vladimir Davydov Cc: tarantool-patches@freelists.org, kostja@tarantool.org List-ID: On Thu, Mar 07, 2019 at 11:27:58AM +0300, Vladimir Davydov wrote: ... > > You can track the ratio of fibers that have overwritten the watermark > recently. If the ratio gets too high (say 90% out of 1000 recently > scheduled fibers), the minimal stack allocation should be increased. IOW, we need to gather statistics :/ I would rather splt this task into two: - make stack 1M by default and madvise as not needed and merge, it upstream asap, to not block users - second series is to optimize stack usage > > > > This won't work. Imagine we put wmark in _first_ page, and then we find > > that the wmark has been overwriten, where to put next mark then? Or > > you propose to catch signals? > > Put the next watermark in the second page then. If it gets overwritten, > too, put it in the third page, and so on. Perhaps, we can even double > the minimal stack allocation each time. ok > > > > > > Why not rand? > > > > Because we already have a helper for random numbers :) > > It's a helper for filling an array with random bytes. I don't see much > point in using it for generating a single random number. ok Cyrill