From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBOdk-00016B-23 for qemu-devel@nongnu.org; Wed, 14 Jan 2015 09:09:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBOdf-00052q-0J for qemu-devel@nongnu.org; Wed, 14 Jan 2015 09:09:43 -0500 Received: from cantor2.suse.de ([195.135.220.15]:50092 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBOde-0004zv-Kl for qemu-devel@nongnu.org; Wed, 14 Jan 2015 09:09:38 -0500 Message-ID: <54B67894.7080001@suse.de> Date: Wed, 14 Jan 2015 15:09:24 +0100 From: Alexander Graf 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> <54B673F2.10301@redhat.com> <20150114140703.GI5136@noname.redhat.com> In-Reply-To: <20150114140703.GI5136@noname.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 , Paolo Bonzini Cc: qemu-devel@nongnu.org, Stefan Hajnoczi On 01/14/15 15:07, Kevin Wolf wrote: > 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. We could just write mprotect an excessively mapped page as guard page, no? > Anyway, the thread pool workers aren't affected by any of this, so they > would be the obvious first step. Yes, ideally we would have the maximum number of threads be runtime configurable too. That way you can adjust them to your workload. Alex