On Wed, 26 Feb 2020 at 08:44, Philippe Mathieu-Daudé <phi...@redhat.com> wrote:
>
> On 2/26/20 9:41 AM, Peter Maydell wrote:
> > On Tue, 25 Feb 2020 at 23:08, Niek Linnenbank <nieklinnenb...@gmail.com>
> > 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/20200219160953.13771-1-imamm...@redhat.com' 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
