qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Desnogues <laurent.desnogues@gmail.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 5/5] tcg/arm: improve direct jump
Date: Wed, 10 Oct 2012 16:43:32 +0200	[thread overview]
Message-ID: <CABoDooMTBeXoP_uU1=ZqxEHmn77Mz3RQEt_hSpSRPdMKC2_Dmw@mail.gmail.com> (raw)
In-Reply-To: <20121010142823.GM9643@ohm.aurel32.net>

On Wed, Oct 10, 2012 at 4:28 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Wed, Oct 10, 2012 at 03:21:48PM +0200, Laurent Desnogues wrote:
>> On Tue, Oct 9, 2012 at 10:30 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > Use ldr pc, [pc, #-4] kind of branch for direct jump. This removes the
>> > need to flush the icache on TB linking, and allow to remove the limit
>> > on the code generation buffer.
>>
>> I'm not sure I like it.  In general having data in the middle
>> of code will increase I/D cache and I/D TLB pressure.
>
> Agreed. On the other hand, this patch remove the synchronization of
> the instruction cache for TB linking/unlinking.

TB linking/unlinking should happen less often than code execution.

>> > This improves the boot-up speed of a MIPS guest by 11%.
>>
>> Boot speed is very specific.  Did you test some other code?
>> Also what was your host?
>
> I tested it on a Cortex-A8 machine. I have only tested MIPS, but I can
> do more tests, like running the openssl testsuite in the emulated guest.

Yes, please.

[...]
> This doesn't really surprise me. The goal of the patch is to remove the
> limit of 16MB for the generated code. I really doubt you reach such a
> limit in user mode unless you use some complex code.
>
> On the other hand in system mode, this can be already reached once the
> whole guest kernel is translated, so cached code is dropped and has to
> be re-translated regularly. Re-translating guest code is clearly more
> expensive than the increase of I/D cache and I/D TLB pressure.

Ha yes, that's a real problem.  What about having some define
and/or runtime flag to keep both caches sync and your ldr PC
change in QEMU?

> The other way to allow more than 16MB of generated code would be to
> disable direct jump on ARM. It adds one 32-bit constant loading + one
> memory load, but then you don't have the I/D cache and TLB issue.

The performance hit would be even worse :-)


Laurent

      reply	other threads:[~2012-10-10 14:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09 20:30 [Qemu-devel] [PATCH 0/5] tcg/arm: fixes and optimizations Aurelien Jarno
2012-10-09 20:30 ` [Qemu-devel] [PATCH 1/5] tcg/arm: fix TLB access in qemu-ld/st ops Aurelien Jarno
2012-10-09 21:13   ` Peter Maydell
2012-10-10 10:00     ` Laurent Desnogues
2012-10-10 10:08       ` Peter Maydell
2012-10-09 20:30 ` [Qemu-devel] [PATCH 2/5] tcg/arm: fix cross-endian qemu_st16 Aurelien Jarno
2012-10-09 20:30 ` [Qemu-devel] [PATCH 3/5] target-openrisc: remove conflicting definitions from cpu.h Aurelien Jarno
2012-10-09 20:30 ` [Qemu-devel] [PATCH 4/5] tcg/arm: optimize tcg_out_goto_label Aurelien Jarno
2012-10-09 20:30 ` [Qemu-devel] [PATCH 5/5] tcg/arm: improve direct jump Aurelien Jarno
2012-10-10 13:21   ` Laurent Desnogues
2012-10-10 14:28     ` Aurelien Jarno
2012-10-10 14:43       ` Laurent Desnogues [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABoDooMTBeXoP_uU1=ZqxEHmn77Mz3RQEt_hSpSRPdMKC2_Dmw@mail.gmail.com' \
    --to=laurent.desnogues@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).