qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts
Date: Mon, 20 Jul 2015 07:51:40 +1000	[thread overview]
Message-ID: <1437342700.28088.113.camel@kernel.crashing.org> (raw)
In-Reply-To: <55ABE196.6000201@redhat.com>

On Sun, 2015-07-19 at 19:42 +0200, Paolo Bonzini wrote:
> 
> On 19/07/2015 14:11, Benjamin Herrenschmidt wrote:
> > Ok, I assumed incorrectly that 8 was too much based on your changeset
> > comment:
> > 
> > <<
> > At 8k per TLB (for 64-bit host or target), 8 or more modes
> >     make the TLBs bigger than 64k, and some RISC TCG backends do
> >     not like that.  On the affected hosts, cut the TLB size in
> >     half---there is still a measurable speedup on PPC with the
> >     next patch.
> > >>
> >
> > IE, you wrote "8 or more".
> 
> Indeed... at 8 the TLBs are exactly 64k.

Right. Interestingly enough, if I look at the ppc backend, it will
generate one more instruction if we have a >32k offset, so ideally
we should keep the "most used" TLBs below 4. I'm going to ignore
that for now.

Another potential issue is that the ppc env is huge, so we put
CPU_COMMON in the middle, which *hopefully* should keep the TLB  within
range but I need to see what happens to the rest of the tcg_gen_ld_tl()
to things that are further out in the env.

At this stage, I'm keen on keeping the patch as is, with 6 modes, since
as I've indicated, we aren't near supporting guest mode for BookE.

Any commend on the other patches ?

> Paolo
> 
> > I can easily fold back guest vs. HV into BookE, though we don't
> > generally support BookE HV mode anyway in TCG so there's no big hurry in
> > doing so (we need to add support for the shadow SPRs and a bunch of
> > other things for that to work).

  reply	other threads:[~2015-07-19 21:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-18 22:20 [Qemu-devel] [RFC PATCH 1/4] ppc: Remove MMU_MODEn_SUFFIX definitions Benjamin Herrenschmidt
2015-07-18 22:20 ` [Qemu-devel] [RFC PATCH 2/4] tlb: Add "ifetch" argument to cpu_mmu_index() Benjamin Herrenschmidt
2015-07-18 22:20 ` [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts Benjamin Herrenschmidt
2015-07-19 11:56   ` Paolo Bonzini
2015-07-19 12:11     ` Benjamin Herrenschmidt
2015-07-19 17:42       ` Paolo Bonzini
2015-07-19 21:51         ` Benjamin Herrenschmidt [this message]
2015-07-19 23:01     ` Aurelien Jarno
2015-07-19 23:33       ` Benjamin Herrenschmidt
2015-07-20  7:11         ` Aurelien Jarno
2015-07-20  8:12           ` Benjamin Herrenschmidt
2015-07-18 22:20 ` [Qemu-devel] [RFC PATCH 4/4] ppc: Do some batching of TCG tlb flushes Benjamin Herrenschmidt

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=1437342700.28088.113.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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).