qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v3 00/13] Slow-path for atomic instruction transla


From: alvise rigo
Subject: Re: [Qemu-devel] [RFC v3 00/13] Slow-path for atomic instruction translation
Date: Fri, 10 Jul 2015 10:58:22 +0200

Hi Mark,

On Fri, Jul 10, 2015 at 10:31 AM, Mark Burton <address@hidden> wrote:
> <big snip>
> To be clear, for a normal user (e.g. they boot linux, they run some apps, 
> etc)..., if they use only one core, is it true that they will see no 
> difference in performance?

I didn't test the one core scenario, but I expect less than 10% of
degradation of this solution compared to upstream (confirmed by a
quick test booting Linux).
Actually the performance of these patches for a unicore system can be
improved, I will keep this in mind for the next release.

> For a ‘normal user’ who does use multi-core, are you saying that a typical 
> boot is slower?

Slower than what?

Regards,
alvise

>
> Cheers
>
> Mark.
>
>> On 10 Jul 2015, at 10:23, Alvise Rigo <address@hidden> wrote:
>>
>> * Performance considerations
>> This implementation shows good results while booting a Linux kernel,
>> where tons of flushes affect the overall performance. A complete ARM
>> Linux boot, without any filesystem, requires 30% longer if compared to
>> the mttcg implementation, benefiting however of being capable to offer
>> the infrastructure to handle atomic instructions on any architecture.
>> Instead compared to the current TCG upstream, it is 40% faster with four
>> vCPUs and 2.1 times faster with 8 vCPUs.
>> In addition, there is still margin to improve such performance, since at
>> the moment TLB is flushed quite often, probably more than the required.
>
>
>          +44 (0)20 7100 3485 x 210
>  +33 (0)5 33 52 01 77x 210
>
>         +33 (0)603762104
>         mark.burton
>
>
>
>



reply via email to

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