Re: Sudden slowdown of ARM emulation in master

[Peter Maydell]

On Wed, 26 Feb 2020 at 08:44, Philippe Mathieu-Daudé <address@hidden> wrote:
>
> On 2/26/20 9:41 AM, Peter Maydell wrote:
> > On Tue, 25 Feb 2020 at 23:08, Niek Linnenbank <address@hidden> wrote:
> >
> >> Just now I was working on some small fixes for the cubieboard machine and 
> >> rebasing my Allwinner H3 branches.
> >> While doing some testing, I noticed that suddenly the machines were much 
> >> slower than before.
> >> I only see this happening when I rebase to this commit:
> >>     ca6155c0f2bd39b4b4162533be401c98bd960820 ("Merge tag 
> >> 'patchew/address@hidden' of https://github.com/patchew-project/qemu into 
> >> HEAD")
> >
> > Yeah, I noticed a slowdown yesterday as well, but haven't tracked it down
> > as yet. The first thing would be to do a git bisect to try to narrow
> > down what commit caused it.
>
> My guess: biggest chunk of memory is the DRAM, registered as "fast RAM"
> by QEMU, but the SoCs provide SRAM which is supposed to be faster. Not
> anymore with QEMU. And Linux try to use the SRAM when possible.

Doesn't sound very likely to me: generally Linux doesn't use random small
lumps of SRAM, it just goes for whatever the dtb says is the main RAM,
usually DRAM. And I thought that all RAM blocks within QEMU performed
the same?

>From the commit that Howard tracked down as the cause it looks like
an ordering-of-actions issue in vl.c where something that was assuming
memory-size-related stuff was set up is now running before those
variables/fields are set correctly rather than after ?

thanks
-- PMM