qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "J. Mayer" <l_indien@magic.fr>
To: Thiemo Seufer <ths@networkno.de>
Cc: qemu-devel@nongnu.org
Subject: Re: [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]
Date: Sat, 13 Oct 2007 23:11:30 +0200	[thread overview]
Message-ID: <1192309890.9976.346.camel@rapid> (raw)
In-Reply-To: <20071013190710.GO3379@networkno.de>

On Sat, 2007-10-13 at 20:07 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > My idea of always using the ldx_code_p function is that we may have the
> > > occasion to make it more cleaver and make the slow case handle code
> > > execution in mmio areas, when it will be possible.
> > 
> > Here's an updated patch. I added a definition TARGET_HAS_VLE_INSNS which
> > is defined is the cris, i386, m68k and ppcemb cases. Arm already has an
> > explicit support for 32 bits thumb instructions spanning 2 pages, so it
> > should not need this define. When this define is not set, the
> > ldxxx_code_p function just does ldxxx_raw(phys_pc) in the softmmu case
> > and ldxxx_raw(pc) in the user-mode only case. This is optimal for pure
> > RISC architectures and does not need the #ifdef CONFIG_USER_ONLY you
> > added for Sparc in your patch version. I also added a provision for a
> > TARGET_MMIO_CODE define which may be used later when this will really be
> > supported by Qemu.
> > I also took your fixes for Sparc phys_pc computation, but reversed your
> > patch to use ldl_raw as it should not be needed anymore.
> > I did test PowerPC in user-mode only and softmmu mode and i386 in
> > softmmu successfully using this new version of the patch.
> 
> Works ok for MIPS. There's no obvious change in performance, I guess
> the slow TLB emulation drowns out any possible improvement.

Great !
Yes, the optimisation we got here is more a 'don't waste our time doing
unneeded things' than a great performance boost. Running a long test
program in linux user mode seems to indicate it spend a little less time
in user-mode when the patch is applied, but this is not very significant
compared to the total time spent in execution. Maybe gprof would show us
if we really spend less time in the translation process...

-- 
J. Mayer <l_indien@magic.fr>
Never organized

  reply	other threads:[~2007-10-13 21:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12 23:00 [Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation] J. Mayer
2007-10-13  7:11 ` Blue Swirl
2007-10-13  9:57   ` J. Mayer
2007-10-13 11:05     ` J. Mayer
2007-10-13 11:58       ` Blue Swirl
2007-10-13 19:07       ` Thiemo Seufer
2007-10-13 21:11         ` J. Mayer [this message]
2007-10-13 11:08     ` Blue Swirl

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=1192309890.9976.346.camel@rapid \
    --to=l_indien@magic.fr \
    --cc=qemu-devel@nongnu.org \
    --cc=ths@networkno.de \
    /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).