From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9802AC07E94 for ; Fri, 4 Jun 2021 07:59:52 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0A2B26141A for ; Fri, 4 Jun 2021 07:59:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A2B26141A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:49522 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp4kA-0006ie-Vu for qemu-devel@archiver.kernel.org; Fri, 04 Jun 2021 03:59:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp4ja-000643-Q0 for qemu-devel@nongnu.org; Fri, 04 Jun 2021 03:59:14 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:41689) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lp4jY-0000Cn-KO for qemu-devel@nongnu.org; Fri, 04 Jun 2021 03:59:14 -0400 Received: by mail-wr1-x431.google.com with SMTP id h8so8308653wrz.8 for ; Fri, 04 Jun 2021 00:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=1vPZWtTk1XpQ+dOLNYS/cdav0ifwDEI4Fy5thNTdWz0=; b=iqWbbuZxpXoz43xgQiq44XFOd0GI9c17u0+qx8J8T98s9DypK/sQLgmMGlg+2rBkqS J9rNMwsAIrC6HlM2yHSSW8FtPOSugHl0uvlguHoEknc1LVqBp/VzkrbhSA5t8EPM5uTx Rr+nF+Wd98EE8rEn4qIV1lbkSlPKc7Hv2iZxrqRnSmzmdbr82m/JX4MSFXePFChz3SB7 q33CLG4DSuyskARIyVHWlgK3Nmx+O8uongaFi8a001EjQ3FWxuEMAGeiHYCUtle21z9a 1RkOZgdLyGp2fr0DhV4IJ9vUVplRFS9ra/zoi3U7++KwdHmsCJd1h2oaZX2nAPQdfOdA gf5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=1vPZWtTk1XpQ+dOLNYS/cdav0ifwDEI4Fy5thNTdWz0=; b=iFbcGLBPMu6AFYFCrcV6J7CTnvM4PsLAW/2twPSU7ZpvtE+f2U1CFWcU//+Flq4aqc HmHApt541+spmSd+cW14vjW+nOFPO0XxXZPQ/FD68Kv7i9AgkVWDplM2kHV2gPKNVo5k M3KZp7iq5sUVAVhLPHEj/U4EXzCcCdlYGxZfaXyUEiKgDJJj+e3Se9Ia+hcuisCcOk3o XtXMIXnba+1XY/7h5SF0NiZ5EDZCBZagXeD2OOohnOXb2c5Ae8f0Fzpq022xoPM5kKcm vgOlyKjOgud2J8Kna+HMcOxfBagFdJ3yR78iu3zUyw2MoMUWQl8jP6Ys/GrnsIIL1PNT 5x7A== X-Gm-Message-State: AOAM532SPtZgX9BT/Itq5MlKHCfjIcPHF43OwI7GVM724sd/iJW4o+I+ Ic1xZTZN9bdwFi3vLiLvvieo4Q== X-Google-Smtp-Source: ABdhPJwF+bnComuyFsm9PFUy7+MZ9r2g6JlcfD2PaQEHJEng0FUBJsJoy4eAG9IY1hP4CSI3mJ6jLw== X-Received: by 2002:a5d:6284:: with SMTP id k4mr2458493wru.312.1622793551228; Fri, 04 Jun 2021 00:59:11 -0700 (PDT) Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id s62sm8079196wms.13.2021.06.04.00.59.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 00:59:10 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 8E1111FF7E; Fri, 4 Jun 2021 08:59:09 +0100 (BST) References: <20210525164541.17985-1-alex.bennee@linaro.org> <76648788-26c3-f957-ac39-eee1600e57f7@linaro.org> User-agent: mu4e 1.5.13; emacs 28.0.50 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Richard Henderson Subject: Re: [RFC PATCH] accel/tcg: change default codegen buffer size for i386-softmmu Date: Fri, 04 Jun 2021 08:42:42 +0100 In-reply-to: <76648788-26c3-f957-ac39-eee1600e57f7@linaro.org> Message-ID: <87o8cm6oxe.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=alex.bennee@linaro.org; helo=mail-wr1-x431.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Thomas Huth , 1896298@bugs.launchpad.net, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Richard Henderson writes: > On 5/25/21 9:45 AM, Alex Benn=C3=A9e wrote: >> There are two justifications for making this change. The first is that >> i386 emulation is typically for smaller machines where having a 1gb of >> generated code is overkill for basic emulation. The second is the >> propensity of self-modifying code (c.f. Doom/edit) utilised on i386 >> systems can trigger a rapid growth in invalidated and re-translated >> buffers. This is seen in bug #283. Execution is still inefficient but >> at least the host memory isn't so aggressively used up. >> That said it's still really just a sticking plaster for user >> convenience. >> Signed-off-by: Alex Benn=C3=A9e >> Cc: Thomas Huth >> Cc: 1896298@bugs.launchpad.net >> --- >> accel/tcg/translate-all.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c >> index 640ff6e3e7..f442165674 100644 >> --- a/accel/tcg/translate-all.c >> +++ b/accel/tcg/translate-all.c >> @@ -951,9 +951,13 @@ static void page_lock_pair(PageDesc **ret_p1, tb_pa= ge_addr_t phys1, >> * Users running large scale system emulation may want to tweak their >> * runtime setup via the tb-size control on the command line. >> */ >> +#ifdef TARGET_I386 >> +#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB) >> +#else >> #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB) >> #endif >> #endif >> +#endif >> #define DEFAULT_CODE_GEN_BUFFER_SIZE \ >> (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \ >>=20 > > I'm not thrilled, as it is ultra-hacky. I don't disagree. > (1) I've got a re-org of this code out for review: > https://patchew.org/QEMU/20210502231844.1977630-1-richard.henderson@linar= o.org/ OK I'll have a look at that. > (2) I'm keen to reorg TCG such that it gets compiled once. There's > currently nothing standing in the way of that except work. But this > would introduce a use of a target-specific define for the first time > into tcg/. I guess I could leave the default sizing back in > accel/tcg/ and pass in the default. > > Other options? Some random thoughts in no particular order: - a separately flushable translation region for code we detect as SMC heavy - a front-end interpreter for SMC code - smarter code generation that dynamically loads values from codemem (usually the SMC code is just tweaking an #imm value) None of these seem particularly amenable to a clean non-complex implementation though. A front-end interpreter would be useful for other things though - it could even be incomplete and handle only common code patterns falling back to full generation for anything it can't handle. > > > r~ --=20 Alex Benn=C3=A9e From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4600CC47083 for ; Fri, 4 Jun 2021 08:12:25 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 937A9613F8 for ; Fri, 4 Jun 2021 08:12:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 937A9613F8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp4wJ-0001zH-Dc for qemu-devel@archiver.kernel.org; Fri, 04 Jun 2021 04:12:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp4vi-0001K3-0u for qemu-devel@nongnu.org; Fri, 04 Jun 2021 04:11:46 -0400 Received: from indium.canonical.com ([91.189.90.7]:38224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lp4vc-0008D4-9a for qemu-devel@nongnu.org; Fri, 04 Jun 2021 04:11:45 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.93 #5 (Debian)) id 1lp4vW-0002g5-MI for ; Fri, 04 Jun 2021 08:11:35 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 739C72E81A6 for ; Fri, 4 Jun 2021 08:11:24 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 04 Jun 2021 07:42:42 -0000 From: =?utf-8?q?Alex_Benn=C3=A9e?= <1896298@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=Expired; importance=Undecided; assignee=None; X-Launchpad-Bug-Tags: tcg X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: ajbennee mslade th-huth X-Launchpad-Bug-Reporter: Michael Slade (mslade) X-Launchpad-Bug-Modifier: =?utf-8?q?Alex_Benn=C3=A9e_=28ajbennee=29?= References: <160046874518.13612.4861858859499751315.malonedeb@gac.canonical.com> Message-ID: <87o8cm6oxe.fsf@linaro.org> Subject: [Bug 1896298] Re: [RFC PATCH] accel/tcg: change default codegen buffer size for i386-softmmu X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="b45bdbe3a00b6b668fa7f2069bd545c35c41f7f4"; Instance="production" X-Launchpad-Hash: c62a77720d5be7e9fa92b6a79093dd29f781a341 Received-SPF: none client-ip=91.189.90.7; envelope-from=bounces@canonical.com; helo=indium.canonical.com X-Spam_score_int: -65 X-Spam_score: -6.6 X-Spam_bar: ------ X-Spam_report: (-6.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1896298 <1896298@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20210604074242.YSnxTVaUOSvvlVhNQA4OX8ANtYCOzWKCAHuoirSXLTo@z> Richard Henderson writes: > On 5/25/21 9:45 AM, Alex Benn=C3=A9e wrote: >> There are two justifications for making this change. The first is that >> i386 emulation is typically for smaller machines where having a 1gb of >> generated code is overkill for basic emulation. The second is the >> propensity of self-modifying code (c.f. Doom/edit) utilised on i386 >> systems can trigger a rapid growth in invalidated and re-translated >> buffers. This is seen in bug #283. Execution is still inefficient but >> at least the host memory isn't so aggressively used up. >> That said it's still really just a sticking plaster for user >> convenience. >> Signed-off-by: Alex Benn=C3=A9e >> Cc: Thomas Huth >> Cc: 1896298@bugs.launchpad.net >> --- >> accel/tcg/translate-all.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c >> index 640ff6e3e7..f442165674 100644 >> --- a/accel/tcg/translate-all.c >> +++ b/accel/tcg/translate-all.c >> @@ -951,9 +951,13 @@ static void page_lock_pair(PageDesc **ret_p1, tb_pa= ge_addr_t phys1, >> * Users running large scale system emulation may want to tweak their >> * runtime setup via the tb-size control on the command line. >> */ >> +#ifdef TARGET_I386 >> +#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB) >> +#else >> #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB) >> #endif >> #endif >> +#endif >> #define DEFAULT_CODE_GEN_BUFFER_SIZE \ >> (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \ >> = > > I'm not thrilled, as it is ultra-hacky. I don't disagree. > (1) I've got a re-org of this code out for review: > https://patchew.org/QEMU/20210502231844.1977630-1-richard.henderson@linar= o.org/ OK I'll have a look at that. > (2) I'm keen to reorg TCG such that it gets compiled once. There's > currently nothing standing in the way of that except work. But this > would introduce a use of a target-specific define for the first time > into tcg/. I guess I could leave the default sizing back in > accel/tcg/ and pass in the default. > > Other options? Some random thoughts in no particular order: - a separately flushable translation region for code we detect as SMC heavy - a front-end interpreter for SMC code - smarter code generation that dynamically loads values from codemem (usually the SMC code is just tweaking an #imm value) None of these seem particularly amenable to a clean non-complex implementation though. A front-end interpreter would be useful for other things though - it could even be incomplete and handle only common code patterns falling back to full generation for anything it can't handle. > > > r~ -- = Alex Benn=C3=A9e -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896298 Title: TCG memory leak with FreeDOS 'edit' Status in QEMU: Expired Bug description: qemu trunk as of today leaks memory FAST when freedos' edit is running. To reproduce, download: https://www.ibiblio.org/pub/micro/pc- stuff/freedos/files/repositories/1.3/cdrom.iso Then run: $ qemu-system-i386 -cdrom cdrom.iso select your language then select "return to DOS", then type > edit it will consume memory at ~10MB/s This does NOT happen when adding -enable-kvm To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1896298/+subscriptions