qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid f


From: Benjamin Herrenschmidt
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

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 via email to

[Prev in Thread] Current Thread [Next in Thread]