From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an2cH-0007xh-BM for qemu-devel@nongnu.org; Mon, 04 Apr 2016 07:24:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1an2cD-0004RY-8w for qemu-devel@nongnu.org; Mon, 04 Apr 2016 07:24:21 -0400 Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:34900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an2cC-0004RU-SU for qemu-devel@nongnu.org; Mon, 04 Apr 2016 07:24:17 -0400 Received: by mail-lf0-x232.google.com with SMTP id c126so46446488lfb.2 for ; Mon, 04 Apr 2016 04:24:16 -0700 (PDT) References: <87y48tu53d.fsf@linaro.org> <57022D7A.1040507@redhat.com> <57024478.2080506@gmail.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <57024478.2080506@gmail.com> Date: Mon, 04 Apr 2016 12:24:14 +0100 Message-ID: <87wpodty5d.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Should we introduce a TranslationRegion with its own codegen buffer? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov Cc: MTTCG Devel , Peter Maydell , QEMU Developers , Cota@braap.org, Paolo Bonzini , Richard Henderson Sergey Fedorov writes: > On 04/04/16 12:01, Paolo Bonzini wrote: >> On 04/04/2016 10:54, Alex Bennée wrote: >>> Thoughts, objections? Discuss ;-) >> I think we're putting a lot of carts before the horse. It is a very valid objection. I don't want to add another major code change in while getting everything else lined up. However I thought it merited discussion if it makes solving some of the other problems easier. >> >> We have like half a dozen subprojects and none are moving because >> there's no clear idea of what to do next and why. The first thing to do >> is to focus on fixing and speeding up user-mode MTTCG (Sergey's work on >> upstreaming the patches from Fred and me) and on upstreaming Alvise's >> work on ll/sc and TLB flushes. FWIW I've dropped the patch that moves tb_find_fast out of tb_lock in the upcoming base-patches-v2 series because it: - weirdly breaks the pxe tests - is pretty ugly anyway This is obviously going to have an impact on performance which bought me back to should we be thinking more holistically about how to approach this problem. In terms of focus I'm currently interested in getting Sergey's cleanups in (which stand on their own merit of being generally cleaner for TCG) and having a solid base-patches that is of use to everyone for testing out the various solutions. After the base patches are out I was going to rebuild Fred's multi_tcg_v8 tree as *a* working implementation for ARMv7 based on a hopefully firm foundation. I'm also looking forward to Emilio's upcoming tree and Alvise's stop-the-world solution. >> The second thing to do is to make tb_flush thread safe; here there are >> three competing mechanisms (Fred's run_safe_on_cpu, Emilio's mass >> invalidation and my idea of using RCU) that we can discuss. Your idea >> here is a fourth one. It's not a bad one, not at all. But even if it >> has other positive side effects (e.g. easier jump patching), it's a >> large project to embark on when there are at least three other >> possibilities---two of them with code and the third (mine) being a >> subset of yours. - async_safe_work I think this works but I've certainly found corner cases. Under heavy load the various vCPU queues do not drain evenly so you end up with high memory usage and the later CPUs having 1000s of deferred tasks. - Emilio's mass invalidation I need to re-read his series to remind myself of what's going on here. To be honest as I know he was re-spinning I was going to wait until the next iteration. - RCU based approaches As you say the two approaches are related, one is just an extension of the other but with a little more indirection. I'm fairly confident the architecture works as I've seen it used in other similar systems but making it work for QEMU is potentially messy implementation detail. > I would agree with Paolo that this may be a bit ahead of time. But > actually, this is an interesting idea we should definitely keep in mind > while we're focused on more immediate work and concerning the overall > design on MTTCG project. My thoughts was such an approach could obviate the need to clean up the existing patching code. But it is a big change so there is a certain wisdom in continuing with the current less radical clean-up even if we envision a future when we can throw that new code away ;-) -- Alex Bennée