From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBObI-0008Me-J7 for qemu-devel@nongnu.org; Wed, 14 Jan 2015 09:07:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBObD-0003xG-KC for qemu-devel@nongnu.org; Wed, 14 Jan 2015 09:07:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBObD-0003x8-Bi for qemu-devel@nongnu.org; Wed, 14 Jan 2015 09:07:07 -0500 Date: Wed, 14 Jan 2015 15:07:03 +0100 From: Kevin Wolf Message-ID: <20150114140703.GI5136@noname.redhat.com> 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> <54B673F2.10301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B673F2.10301@redhat.com> 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: Paolo Bonzini Cc: Alexander Graf , Stefan Hajnoczi , qemu-devel@nongnu.org Am 14.01.2015 um 14:49 hat Paolo Bonzini geschrieben: > > > 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. Maybe that's the easiest one, yes. > >> 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. Basically block.c would do something like get_block_status() first and only then call the read/write functions of the individual drivers. But yes, that's more a theoretical consideration at this point. I think with the 50 recursions that you calculated we should be fine in practice for now. I would however strongly recommend finally implementing a guard page for coroutine stacks before we make that change. Anyway, the thread pool workers aren't affected by any of this, so they would be the obvious first step. Kevin