Re: RT Xen on ARM - R-Car series

From: Julien Grall <julien.grall@gmail.com>
To: Andrii Anisov <andrii.anisov@gmail.com>
Cc: Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Xen Devel <xen-devel@lists.xen.org>,
	"LOPEZ, FUENTES NACARINO Jairo Eduardo" <jairo@ruri.waseda.jp>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: RT Xen on ARM - R-Car series
Date: Thu, 14 Feb 2019 18:29:08 +0100	[thread overview]
Message-ID: <CAF3u54Dw4n+6HwyQ8-pXMNNMZbu4xVrTh9aV-WAe-XUxhoG1-g@mail.gmail.com> (raw)
In-Reply-To: <fee642a7-9a1a-53f1-b0a3-6f47ec0b15cc@gmail.com>

On Thu, Feb 14, 2019 at 3:18 PM Andrii Anisov <andrii.anisov@gmail.com> wrote:
>
> Hello Julien,

Hi,

Sorry for the formatting, I am using the gmail web-interface for once.

> On 12.02.19 21:21, Julien Grall wrote:
> > Please provide more meaningful arguments other than "I don't like it". I provided potential drawbacks on my previous e-mails that you haven't yet addressed.
>
> Well, currently, on each runstate update, `copy_to_guest()` which translates the buffer virtual address is called three times. On context switch, runstate update is done twice, when we change a vcpu.

I am not sure why you are speaking about the current implementation
when my point was about the new implementation.

I guess your point stick even if we decide to use guest physical
address. Although, I am still unconvinced of the benefits to keep it
mapped.

>
> > FWIW, Volodymyr had the same argument on OP-TEE and I requested to avoid the global mapping. I haven't seen any concern for performance devredation afterwards. Please feel free to come with numbers here.
> The numbers here are controversial and really confusing to me.
> I've measured the raw `update_runstate_area()` execution time. With runstate mapped - its execution time is less than my timer tick (120ns), with runstate not mapped - I've seen
its execution time as 4 to 8 ticks (480-960ns).

Please provide the code you use to measure it. How often do you call it?

> But using TBM, I encountered that making runstate mapped with Roger's patch increases the IRQ latency from ~7000ns to ~7900ns. It is opposite to my expectations and to the raw decrease of `runstate_update_area()` execution time.

Raw benchmarks should be taken with a grain of salt. The more if you
only benchmark a single function as the context switch may introduce
latency/cache eviction.

Although, I would have expected the numbers to be the same. What is
your configuration here? Do you have others guests running? How many
context switch do you have?

Also, what are the modifications you made in TBM to use runstate?

> Also glmark2 benchmark shown me slight performance drop on getting runstate mapping.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel