On Fri, Nov 16, 2018 at 09:10:32 +0100, Richard Henderson wrote:
> On 11/16/18 2:13 AM, Emilio G. Cota wrote:
> > This allows us to discard most TBs; in the example above,
> > we end up *not* discarding only ~70 TBs, that is we end up keeping
> > only 70/2500 = 2.8% of the TBs that we'd discard
On Fri, Nov 16, 2018 at 09:07:50 +0100, Richard Henderson wrote:
> On 11/16/18 6:10 AM, Emilio G. Cota wrote:
> > It's possible that newer machines with larger reorder buffers
> > will be able to take better advantage of the higher instruction
> > locality, hiding the latency of having to execute
On 11/16/18 2:13 AM, Emilio G. Cota wrote:
> This allows us to discard most TBs; in the example above,
> we end up *not* discarding only ~70 TBs, that is we end up keeping
> only 70/2500 = 2.8% of the TBs that we'd discard without OOL.
Thanks.
When I apply this I think I'll rename "n_ool_thunks"
On 11/16/18 6:10 AM, Emilio G. Cota wrote:
> It's possible that newer machines with larger reorder buffers
> will be able to take better advantage of the higher instruction
> locality, hiding the latency of having to execute more instructions.
> I'll test on Skylake tomorrow.
I've noticed that
On Thu, Nov 15, 2018 at 20:13:38 -0500, Emilio G. Cota wrote:
> I'll generate now some more perf numbers that we could include in the
> commit logs.
SPEC numbers are a net perf decrease, unfortunately:
Softmmu speedup for SPEC06int (test set)
1.1
On Thu, Nov 15, 2018 at 23:04:50 +0100, Richard Henderson wrote:
> On 11/15/18 7:48 PM, Emilio G. Cota wrote:
> > - Segfault in code_gen_buffer. This one I don't have a fix for,
> > but it's *much* easier to reproduce when -tb-size is very small,
> > e.g. "-tb-size 5 -smp 2" (BTW it crashes
On 11/15/18 7:48 PM, Emilio G. Cota wrote:
> - Segfault in code_gen_buffer. This one I don't have a fix for,
> but it's *much* easier to reproduce when -tb-size is very small,
> e.g. "-tb-size 5 -smp 2" (BTW it crashes with x86_64 guests too.)
> So at first I thought the code cache flushing
On 11/15/18 7:48 PM, Emilio G. Cota wrote:
> - All TCG contexts end up using the same hash table, since
> we only allocate one table in tcg_context_init. This leads
> to memory corruption.
Bah. I forgot we only call tcg_context_init once.
Thanks for the fix.
In the meantime I've fixed the
On Thu, Nov 15, 2018 at 12:32:00 +0100, Richard Henderson wrote:
> On 11/14/18 2:00 AM, Emilio G. Cota wrote:
> > The following might be related: I'm seeing segfaults with -smp 8
> > and beyond when doing bootup+shutdown of an aarch64 guest on
> > an x86-64 host.
>
> I'm not seeing that.
On 11/14/18 2:00 AM, Emilio G. Cota wrote:
> The following might be related: I'm seeing segfaults with -smp 8
> and beyond when doing bootup+shutdown of an aarch64 guest on
> an x86-64 host.
I'm not seeing that. Anything else special on the command-line?
Are the segv in the code_gen_buffer or
On Mon, Nov 12, 2018 at 22:44:46 +0100, Richard Henderson wrote:
> Based on an idea forwarded by Emilio, which suggests a 5-6%
> speed gain is possible. I have not spent too much time
> measuring this, as the code size gains are significant.
Nice!
> I believe that I posted an x86_64-only patch
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20181112214503.22941-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH for-4.0 00/17] tcg: Move softmmu out-of-line
=== TEST SCRIPT BEGIN ===
#!/bin/bash
12 matches
Mail list logo
