From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBOKQ-0007wa-Ig for qemu-devel@nongnu.org; Wed, 14 Jan 2015 08:49:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBOKO-0005SB-S7 for qemu-devel@nongnu.org; Wed, 14 Jan 2015 08:49:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBOKO-0005Ru-In for qemu-devel@nongnu.org; Wed, 14 Jan 2015 08:49:44 -0500 Message-ID: <54B673F2.10301@redhat.com> Date: Wed, 14 Jan 2015 14:49:38 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1421197016-69426-1-git-send-email-agraf@suse.de> <54B61CD6.7010303@redhat.com> <20150114102026.GE5136@noname.redhat.com> <54B65085.70007@redhat.com> <20150114133805.GG5136@noname.redhat.com> In-Reply-To: <20150114133805.GG5136@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] AIO: Reduce number of threads for 32bit hosts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alexander Graf , Stefan Hajnoczi , qemu-devel@nongnu.org On 14/01/2015 14:38, Kevin Wolf wrote: > Well, what do you want to use it for? I thought it would only be for a > one-time check where we usually end up rather than something that would > be enabled in production, but maybe I misunderstood. No, you didn't. Though I guess we could limit the checks to the yield points. If we have BDS recursion, as in the backing file case, yield points should not be far from the deepest part of the stack. Another possibility (which cannot be enabled in production) is to fill the stack with a known 64-bit value, and do a binary search when the coroutine is destroyed. >> I tried gathering warning from GCC's -Wstack-usage=1023 option and the >> block layer does not seem to have functions with huge stacks in the I/O >> path. >> >> So, assuming a maximum stack depth of 50 (already pretty generous since >> there shouldn't be any recursive calls) a 100K stack should be pretty >> much okay for coroutines and thread-pool threads. > > The potential problem in the block layer is long backing file chains. > Perhaps we need to do something to solve that iteratively instead of > recursively. Basically first read stuff from the current BDS, and then "fill in the blanks" with a tail call on bs->backing_file? That would be quite a change, and we'd need a stopgap measure like Alex's patch in the meanwhile. Paolo