[Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Krzeminski, Marcin (Nokia - PL/Wroclaw)]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Hello,

I am playing with U-Boot on ARM under qemu.
U-boot uses mptimer, and under qemu one second takes about 1 in real world.
At the moment it seem that in u-boot is ok, so I have question about below function.
Why prescaler value is multiply by 10?

static inline uint64_t a9_gtimer_get_conv(A9GTimerState *s)
{
    uint64_t prescale = extract32(s->control, R_CONTROL_PRESCALER_SHIFT,
                                  R_CONTROL_PRESCALER_LEN);

    return (prescale + 1) * 10;
}

Regards,
Marcin


[-- Attachment #2: Type: text/html, Size: 1350 bytes --]

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Dmitry Osipenko]

27.10.2015 16:48, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет:
> Hello,
> I am playing with U-Boot on ARM under qemu.
> U-boot uses mptimer, and under qemu one second takes about 1 in real world.
> At the moment it seem that in u-boot is ok, so I have question about below function.
> Why prescaler value is multiply by 10?
> static inline uint64_t a9_gtimer_get_conv(A9GTimerState *s)
> {
>      uint64_t prescale = extract32(s->control, R_CONTROL_PRESCALER_SHIFT,
>                                    R_CONTROL_PRESCALER_LEN);
>      return (prescale + 1) * 10;
> }
> Regards,
> Marcin

Hello Marcin,

 From my observation, Linux kernel is booting noticeably faster in the emulated 
guest and host machine CPU usage is lower if we "artificially" slowdown the 
MPtimer. You really shouldn't use it for the RTC, so doing that trick shouldn't 
affect guest behavior.

However, maybe there is some other rational behind it and Peter C and/or Peter M 
might know better.

-- 
Dmitry

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Peter Maydell]

On 27 October 2015 at 14:19, Dmitry Osipenko <digetx@gmail.com> wrote:
> 27.10.2015 16:48, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет:
>
>> Hello,
>> I am playing with U-Boot on ARM under qemu.
>> U-boot uses mptimer, and under qemu one second takes about 1 in real
>> world.
>> At the moment it seem that in u-boot is ok, so I have question about below
>> function.
>> Why prescaler value is multiply by 10?
>> static inline uint64_t a9_gtimer_get_conv(A9GTimerState *s)
>> {
>>      uint64_t prescale = extract32(s->control, R_CONTROL_PRESCALER_SHIFT,
>>                                    R_CONTROL_PRESCALER_LEN);
>>      return (prescale + 1) * 10;
>> }

> From my observation, Linux kernel is booting noticeably faster in the
> emulated guest and host machine CPU usage is lower if we "artificially"
> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that
> trick shouldn't affect guest behavior.
>
> However, maybe there is some other rational behind it and Peter C and/or
> Peter M might know better.

My guess is that we're just randomly hard-coding PERIPHCLK to
an effective 100MHz here.

thanks
-- PMM

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Peter Crosthwaite]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko <digetx@gmail.com> wrote:

> 27.10.2015 16:48, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет:
>
> Hello,
>> I am playing with U-Boot on ARM under qemu.
>> U-boot uses mptimer, and under qemu one second takes about 1 in real
>> world.
>> At the moment it seem that in u-boot is ok, so I have question about
>> below function.
>> Why prescaler value is multiply by 10?
>> static inline uint64_t a9_gtimer_get_conv(A9GTimerState *s)
>> {
>>      uint64_t prescale = extract32(s->control, R_CONTROL_PRESCALER_SHIFT,
>>                                    R_CONTROL_PRESCALER_LEN);
>>      return (prescale + 1) * 10;
>> }
>> Regards,
>> Marcin
>>
>
> Hello Marcin,
>
> From my observation, Linux kernel is booting noticeably faster in the
> emulated guest and host machine CPU usage is lower if we "artificially"
> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing
> that trick shouldn't affect guest behavior.
>
> However, maybe there is some other rational behind it and Peter C and/or
> Peter M might know better.
>
>
So I do wonder whether with your ptimer conversion this will be obsoleted,
as the rate limiter there may do the work for us.

Regards,
Peter


> --
> Dmitry
>

[-- Attachment #2: Type: text/html, Size: 2085 bytes --]

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Dmitry Osipenko]

27.10.2015 21:01, Peter Crosthwaite пишет:
>
>
> On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko <digetx@gmail.com
> <mailto:digetx@gmail.com>> wrote:
>
>     27.10.2015 16:48, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет:
>
>         Hello,
>         I am playing with U-Boot on ARM under qemu.
>         U-boot uses mptimer, and under qemu one second takes about 1 in real world.
>         At the moment it seem that in u-boot is ok, so I have question about
>         below function.
>         Why prescaler value is multiply by 10?
>         static inline uint64_t a9_gtimer_get_conv(A9GTimerState *s)
>         {
>               uint64_t prescale = extract32(s->control, R_CONTROL_PRESCALER_SHIFT,
>                                             R_CONTROL_PRESCALER_LEN);
>               return (prescale + 1) * 10;
>         }
>         Regards,
>         Marcin
>
>
>     Hello Marcin,
>
>      From my observation, Linux kernel is booting noticeably faster in the
>     emulated guest and host machine CPU usage is lower if we "artificially"
>     slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that
>     trick shouldn't affect guest behavior.
>
>     However, maybe there is some other rational behind it and Peter C and/or
>     Peter M might know better.
>
>
> So I do wonder whether with your ptimer conversion this will be obsoleted, as
> the rate limiter there may do the work for us.
>
> Regards,
> Peter
>
>     --
>     Dmitry
>
>

You might be right, I haven't tried it without prescale multiplier with recent 
ptimer fixes. Will try and report back.

-- 
Dmitry

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Peter Maydell]

On 27 October 2015 at 18:01, Peter Crosthwaite
<crosthwaitepeter@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko <digetx@gmail.com> wrote:
>> From my observation, Linux kernel is booting noticeably faster in the
>> emulated guest and host machine CPU usage is lower if we "artificially"
>> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that
>> trick shouldn't affect guest behavior.

> So I do wonder whether with your ptimer conversion this will be obsoleted,
> as the rate limiter there may do the work for us.

We still need to pick a nominal PERIPHCLK somehow, and that's
still a pretty arbitrary choice I think (and it doesn't
depend on the CPU speed itself: PERIPHCLK's period can be
any multiple of the main CPU CLK (minimum 2)).

thanks
-- PMM

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Peter Crosthwaite]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

On Tue, Oct 27, 2015 at 11:19 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 27 October 2015 at 18:01, Peter Crosthwaite
> <crosthwaitepeter@gmail.com> wrote:
> > On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko <digetx@gmail.com>
> wrote:
> >> From my observation, Linux kernel is booting noticeably faster in the
> >> emulated guest and host machine CPU usage is lower if we "artificially"
> >> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing
> that
> >> trick shouldn't affect guest behavior.
>
> > So I do wonder whether with your ptimer conversion this will be
> obsoleted,
> > as the rate limiter there may do the work for us.
>
> We still need to pick a nominal PERIPHCLK somehow, and that's
> still a pretty arbitrary choice I think (and it doesn't
> depend on the CPU speed itself: PERIPHCLK's period can be
> any multiple of the main CPU CLK (minimum 2)).
>
>
Yep. But is it nice to know if we can move towards board level
configuration of this without the rate-limiting problem. Rather than a 10x
rate limiter it should be a QOM property for PERIPHCLK frequency.

Regards,
Peter


> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Krzeminski, Marcin (Nokia - PL/Wroclaw)]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]



From: EXT Peter Crosthwaite [mailto:crosthwaitepeter@gmail.com]
Sent: Tuesday, October 27, 2015 7:23 PM
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Dmitry Osipenko <digetx@gmail.com>; Krzeminski, Marcin (Nokia - PL/Wroclaw) <marcin.krzeminski@nokia.com>; qemu-devel@nongnu.org
Subject: Re: arm mptimer implementation - why prescaler is multiply by 10?



On Tue, Oct 27, 2015 at 11:19 AM, Peter Maydell <peter.maydell@linaro.org<mailto:peter.maydell@linaro.org>> wrote:
On 27 October 2015 at 18:01, Peter Crosthwaite
<crosthwaitepeter@gmail.com<mailto:crosthwaitepeter@gmail.com>> wrote:
> On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko <digetx@gmail.com<mailto:digetx@gmail.com>> wrote:
>> From my observation, Linux kernel is booting noticeably faster in the
>> emulated guest and host machine CPU usage is lower if we "artificially"
>> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that
>> trick shouldn't affect guest behavior.
Do you mean qemu or real hw?

> So I do wonder whether with your ptimer conversion this will be obsoleted,
> as the rate limiter there may do the work for us.

We still need to pick a nominal PERIPHCLK somehow, and that's
still a pretty arbitrary choice I think (and it doesn't
depend on the CPU speed itself: PERIPHCLK's period can be
any multiple of the main CPU CLK (minimum 2)).

Yep. But is it nice to know if we can move towards board level configuration of this without the rate-limiting problem. Rather than a 10x rate limiter it should be a QOM property for PERIPHCLK frequency.
Regards,
Peter

thanks
-- PMM

I made some tests by changing implementation to work with PERIPHCLK=600MHz, and in fact overhead was to high to work comfortably with linux guest, but the key problem was networking.

[-- Attachment #2: Type: text/html, Size: 5588 bytes --]

Re: [Qemu-devel] arm mptimer implementation - why prescaler is multiply by 10?

[Dmitry Osipenko]

29.10.2015 10:00, Krzeminski, Marcin (Nokia - PL/Wroclaw) пишет:
> *From:*EXT Peter Crosthwaite [mailto:crosthwaitepeter@gmail.com]
> *Sent:* Tuesday, October 27, 2015 7:23 PM
> *To:* Peter Maydell <peter.maydell@linaro.org>
> *Cc:* Dmitry Osipenko <digetx@gmail.com>; Krzeminski, Marcin (Nokia -
> PL/Wroclaw) <marcin.krzeminski@nokia.com>; qemu-devel@nongnu.org
> *Subject:* Re: arm mptimer implementation - why prescaler is multiply by 10?
>
> On Tue, Oct 27, 2015 at 11:19 AM, Peter Maydell <peter.maydell@linaro.org
> <mailto:peter.maydell@linaro.org>> wrote:
>
>     On 27 October 2015 at 18:01, Peter Crosthwaite
>     <crosthwaitepeter@gmail.com <mailto:crosthwaitepeter@gmail.com>> wrote:
>      > On Tue, Oct 27, 2015 at 7:19 AM, Dmitry Osipenko <digetx@gmail.com
>     <mailto:digetx@gmail.com>> wrote:
>      >> From my observation, Linux kernel is booting noticeably faster in the
>      >> emulated guest and host machine CPU usage is lower if we "artificially"
>      >> slowdown the MPtimer. You really shouldn't use it for the RTC, so doing that
>      >> trick shouldn't affect guest behavior.
>
>     Do you mean qemu or real hw?
>

Both, but it depends on your application and if there is no proper RTC onboard.

>
>      > So I do wonder whether with your ptimer conversion this will be obsoleted,
>      > as the rate limiter there may do the work for us.
>
>     We still need to pick a nominal PERIPHCLK somehow, and that's
>     still a pretty arbitrary choice I think (and it doesn't
>     depend on the CPU speed itself: PERIPHCLK's period can be
>     any multiple of the main CPU CLK (minimum 2)).
>
> Yep. But is it nice to know if we can move towards board level configuration of
> this without the rate-limiting problem. Rather than a 10x rate limiter it should
> be a QOM property for PERIPHCLK frequency.
>
> Regards,
>
> Peter
>
>     thanks
>     -- PMM
>
> I made some tests by changing implementation to work with PERIPHCLK=600MHz, and
> in fact overhead was to high to work comfortably with linux guest, but the key
> problem was networking.
>

Exactly. Once kernel reaches NFS mount here, it starts to suffer.

-- 
Dmitry