[Top][All Lists]

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

Re: [Qemu-arm] [PATCH v3 0/7] Runtime pagesize computation

From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH v3 0/7] Runtime pagesize computation
Date: Fri, 21 Oct 2016 16:00:22 +0100

On 11 October 2016 at 18:08, Peter Maydell <address@hidden> wrote:
> (I posted version 2 way back in June...)
> The basic idea here is that:
>  * the target CPU implementation has to opt into variable page size
>    by defining TARGET_PAGE_BITS_VARY, and then calling
>    set_preferred_target_page_bits() in its realize function
>    with whatever the CPU as instantiated actually requires
>  * the machine also has to opt in, by specifying a new MachineClass
>    field which states the value they guarantee will be no greater
>    than the preferred page size for any CPU they create
>  * we finalize the decision about page size in cpu_exec_init_all()
>    (and then later attempts to create CPUs which can't cope with
>    that decision are failed)

> I have only very lightly tested these and haven't attempted
> to measure performance at all. Further testing and
> benchmarking reports are therefore welcome.
> In particular I would like to know how much of an
> effect on TCG performance the assert() in the definition
> of TARGET_PAGE_BITS has, so comparisons of all three configs:
>  * before this patchset (ie TARGET_PAGE_BITS compile time const)
>  * with this patchset (with assert in TARGET_PAGE_BITS)
>  * this patchset, but with the assert commented out

So I found the time to do some benchmarking. This is of
an ARMv7 guest running a workload that is "boot up
kernel and userspace (via systemd), run a compilation,
then shutdown". This took about 5m9s to run with current
master, and 4m14s with this patchset, cutting nearly 20%
off the runtime. Removing the assert from TARGET_PAGE_BITS
was barely noticeable (down to 4m13s) so I think we should
leave that in.

On that basis and given the code review from rth I'm going to
put this into target-arm.next.

-- PMM

reply via email to

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