Hi all,
year(s) ago it was discovered that MCT timer and ARM architectured
timer
are the same hardware with different interface. Here [1].
I followed mail-list discussions about removing MCT and using arch
timer for Exynos5-based SoCs but things aren't moving at least latest
upstream kernel on odroid-xu3 will use MCT as default timers.
Maybe the reason are some power-management related things that very
specific to Samsung. I don't know.
Idea of this draft patchset comes from Doug patches when he tried to
optimize read of 64-bit counter located in mmio. [2]
Why not using cp15 counter instead if possible?
Previous numbers for 1000000 gettimeofday() calls from userspace
are about 1 ms. With this patches we have 0.5 ms or even better.
So twice as fast.
Just as matter of interest i tried to perform 2000000 sched_yield()
calls from userspace. I see around 20% speedup with patches applied.
I tried to use hackbench but it's hard to feel the difference, maybe
speedup is 0.5% but with bad fluctuation.
Everything is tested on odroid-xu3.
Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't
have arch timer.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014
-May/256943.html
[2] https://lkml.org/lkml/2014/6/20/431
Current code created with such assumptions:
-- don't want to insert huge refactoring in MCT code;
-- target platform only ARMv7 Exynos5-based SoC that works in 32-bit
mode so i don't want to build described functionality on ARM64.
Currently i'm trying to patch odroid-xu3 DT only.
-- firmware on odroid-xu3 is broken and secondary cores start
in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode;
-- in addition instead of DT property I may parse PFR regs and find
Generic Timer Extension there.
I hope you are not getting bored reading to me. Current code is a
little bit draft so comments and ideas are welcome.
Best regards,
Alexey Klimov
On Mon, Jul 27, 2015 at 10:28:27PM +0100, Alexey Klimov wrote:
> Hi all,
>
> year(s) ago it was discovered that MCT timer and ARM architectured
> timer
> are the same hardware with different interface. Here [1].
Are they actually interfaces to the same timer, or are they just fed by
the same system counter?
> I followed mail-list discussions about removing MCT and using arch
> timer for Exynos5-based SoCs but things aren't moving at least latest
> upstream kernel on odroid-xu3 will use MCT as default timers.
> Maybe the reason are some power-management related things that very
> specific to Samsung. I don't know.
>
>
> Idea of this draft patchset comes from Doug patches when he tried to
> optimize read of 64-bit counter located in mmio. [2]
> Why not using cp15 counter instead if possible?
If they're the same device, then you can simply use the architected
timer, and gain all the benefits without additional code. That could
give you additional benefits (e.g. VDSO support).
> Previous numbers for 1000000 gettimeofday() calls from userspace
> are about 1 ms. With this patches we have 0.5 ms or even better.
> So twice as fast.
>
> Just as matter of interest i tried to perform 2000000 sched_yield()
> calls from userspace. I see around 20% speedup with patches applied.
>
> I tried to use hackbench but it's hard to feel the difference, maybe
> speedup is 0.5% but with bad fluctuation.
>
> Everything is tested on odroid-xu3.
> Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't
> have arch timer.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014
> -May/256943.html
> [2] https://lkml.org/lkml/2014/6/20/431
>
>
>
> Current code created with such assumptions:
> -- don't want to insert huge refactoring in MCT code;
> -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit
> mode so i don't want to build described functionality on ARM64.
For arm64 the generic timer is mandatory, and I can't imagine a case
where we wouldn't use it in preference.
> Currently i'm trying to patch odroid-xu3 DT only.
> -- firmware on odroid-xu3 is broken and secondary cores start
> in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode;
> -- in addition instead of DT property I may parse PFR regs and find
> Generic Timer Extension there.
ID_PFR1.GenTimer only tells you whether or not the generic timer is
implemented in the CPU, not how it's wired up (e.g. whether it shares
the system counter with the MCT), so I don't think it tells you anything
useful.
Thanks,
Mark.
On Tue, Jul 28, 2015 at 4:02 PM, Mark Rutland <[email protected]> wrote:
> On Mon, Jul 27, 2015 at 10:28:27PM +0100, Alexey Klimov wrote:
>> Hi all,
>>
>> year(s) ago it was discovered that MCT timer and ARM architectured
>> timer
>> are the same hardware with different interface. Here [1].
>
> Are they actually interfaces to the same timer, or are they just fed by
> the same system counter?
Good question goes to Samsung maintainers.
I can find unanswered mail thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/258576.html
Let me quote Kukjin: " Basically the two blocks are connected and the
arch timer uses the count value from MCT for reference"
>> I followed mail-list discussions about removing MCT and using arch
>> timer for Exynos5-based SoCs but things aren't moving at least latest
>> upstream kernel on odroid-xu3 will use MCT as default timers.
>> Maybe the reason are some power-management related things that very
>> specific to Samsung. I don't know.
>>
>>
>> Idea of this draft patchset comes from Doug patches when he tried to
>> optimize read of 64-bit counter located in mmio. [2]
>> Why not using cp15 counter instead if possible?
>
> If they're the same device, then you can simply use the architected
> timer, and gain all the benefits without additional code. That could
> give you additional benefits (e.g. VDSO support).
Right. I like the idea to use arch_timer. Odroid-xu3 works fine with it.
Looks like Samsung have some games with power management stuff that
can't be opened/told and they use MCT that works well for their needs.
This draft patchset is only about little speedup of MCT operations
that still here and used.
To start arch timer we may need to initialize G_TCON register in MCT
like it's done in Xen:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/platforms/exynos5.c;h=79e3a5faf9fa6f37d99040f85c6dccbd9312c856;hb=HEAD
in exynos5_init_time(). I guess not all bootloaders properly
initialize MCT on Exynos5 boards.
If addition of similar platform callback and enable of arch_timer are
steps in right direction I can take a look on it.
Or as suggested in one mail thread: if MCT is present in DT then MCT
driver lookup arch_timer in dt, find it, initialize G_TCON reg and
gives up to allow arch_timer to do it job (in that case we need to
init MCT before arch timer).
>> Previous numbers for 1000000 gettimeofday() calls from userspace
>> are about 1 ms. With this patches we have 0.5 ms or even better.
>> So twice as fast.
>>
>> Just as matter of interest i tried to perform 2000000 sched_yield()
>> calls from userspace. I see around 20% speedup with patches applied.
>>
>> I tried to use hackbench but it's hard to feel the difference, maybe
>> speedup is 0.5% but with bad fluctuation.
>>
>> Everything is tested on odroid-xu3.
>> Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't
>> have arch timer.
>>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014
>> -May/256943.html
>> [2] https://lkml.org/lkml/2014/6/20/431
>>
>>
>>
>> Current code created with such assumptions:
>> -- don't want to insert huge refactoring in MCT code;
>> -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit
>> mode so i don't want to build described functionality on ARM64.
>
> For arm64 the generic timer is mandatory, and I can't imagine a case
> where we wouldn't use it in preference.
Yep. That's why probably MCT isn't used on arm64.
>> Currently i'm trying to patch odroid-xu3 DT only.
>> -- firmware on odroid-xu3 is broken and secondary cores start
>> in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode;
>> -- in addition instead of DT property I may parse PFR regs and find
>> Generic Timer Extension there.
>
> ID_PFR1.GenTimer only tells you whether or not the generic timer is
> implemented in the CPU, not how it's wired up (e.g. whether it shares
> the system counter with the MCT), so I don't think it tells you anything
> useful.
>
> Thanks,
> Mark.
Yep, just only one of the initial points to understand is it any use trying.
Thanks.
Best regards,
Klimov Alexey
Alexey,
On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov <[email protected]> wrote:
> Hi all,
>
> year(s) ago it was discovered that MCT timer and ARM architectured
> timer
> are the same hardware with different interface. Here [1].
>
> I followed mail-list discussions about removing MCT and using arch
> timer for Exynos5-based SoCs but things aren't moving at least latest
> upstream kernel on odroid-xu3 will use MCT as default timers.
> Maybe the reason are some power-management related things that very
> specific to Samsung. I don't know.
>
>
> Idea of this draft patchset comes from Doug patches when he tried to
> optimize read of 64-bit counter located in mmio. [2]
> Why not using cp15 counter instead if possible?
I hate to burst your bubble here, but...
...I think it would be a bad idea to use the cp15 counter on exynos
5422. According to Samsung, there are issues where using cp15 could
sometimes return the wrong value, especially if you happen to read it
while on an A7 instead of an A15. It will tend to work pretty well,
but Samsung claimed that it might not work right on some CPUs or at
some temperatures.
I've added Alim who provided this information to me (in the private
http://crosbug.com/p/29556). He may be able to elaborate more.
Generally I'd say that if the arch timer works for you: use the arch
timer. If the arch timer doesn't work for you, use the MCT.
-Doug
Hi Doug,
On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson <[email protected]> wrote:
> Alexey,
>
> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov <[email protected]> wrote:
>> Hi all,
>>
>> year(s) ago it was discovered that MCT timer and ARM architectured
>> timer
>> are the same hardware with different interface. Here [1].
>>
>> I followed mail-list discussions about removing MCT and using arch
>> timer for Exynos5-based SoCs but things aren't moving at least latest
>> upstream kernel on odroid-xu3 will use MCT as default timers.
>> Maybe the reason are some power-management related things that very
>> specific to Samsung. I don't know.
>>
>>
>> Idea of this draft patchset comes from Doug patches when he tried to
>> optimize read of 64-bit counter located in mmio. [2]
>> Why not using cp15 counter instead if possible?
>
> I hate to burst your bubble here, but...
>
> ...I think it would be a bad idea to use the cp15 counter on exynos
> 5422. According to Samsung, there are issues where using cp15 could
> sometimes return the wrong value, especially if you happen to read it
> while on an A7 instead of an A15. It will tend to work pretty well,
> but Samsung claimed that it might not work right on some CPUs or at
> some temperatures.
I think this is right time when I can say "If only I had known about
it before!".
That's quite interesting especially about temperature issues.
Maybe it's worth to insert comments in driver/docs about this.
> I've added Alim who provided this information to me (in the private
> http://crosbug.com/p/29556). He may be able to elaborate more.
Alim, could you please add details if any?
> Generally I'd say that if the arch timer works for you: use the arch
> timer. If the arch timer doesn't work for you, use the MCT.
>
> -Doug
I possess no knowledge if there're any different hw revisions of
odroid-xu3 on the field
but looks like arch timer works fine for me on odroid-xu3 Exynos5422
SoC with upstream kernel.
Is it right direction to switch xu3 to arch timer?
Do you have any info or ideas about enabling MCT G_TCON register to
start arch timer
and what's the best way to do it?
Thanks.
--
Best regards, Klimov Alexey
Hi,
On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov <[email protected]> wrote:
> Hi Doug,
>
> On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson <[email protected]> wrote:
>> Alexey,
>>
>> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov <[email protected]> wrote:
>>> Hi all,
>>>
>>> year(s) ago it was discovered that MCT timer and ARM architectured
>>> timer
>>> are the same hardware with different interface. Here [1].
>>>
>>> I followed mail-list discussions about removing MCT and using arch
>>> timer for Exynos5-based SoCs but things aren't moving at least latest
>>> upstream kernel on odroid-xu3 will use MCT as default timers.
>>> Maybe the reason are some power-management related things that very
>>> specific to Samsung. I don't know.
>>>
>>>
>>> Idea of this draft patchset comes from Doug patches when he tried to
>>> optimize read of 64-bit counter located in mmio. [2]
>>> Why not using cp15 counter instead if possible?
>>
>> I hate to burst your bubble here, but...
>>
>> ...I think it would be a bad idea to use the cp15 counter on exynos
>> 5422. According to Samsung, there are issues where using cp15 could
>> sometimes return the wrong value, especially if you happen to read it
>> while on an A7 instead of an A15. It will tend to work pretty well,
>> but Samsung claimed that it might not work right on some CPUs or at
>> some temperatures.
>
> I think this is right time when I can say "If only I had known about
> it before!".
Yeah, we spent a whole lot of time on this too before giving up after
we found out it was not possible to use.
> That's quite interesting especially about temperature issues.
> Maybe it's worth to insert comments in driver/docs about this.
Maybe not a bad idea. Depends if you think someone else will try to
do this... ...and if they do, will they check mailing list traffic.
>> Generally I'd say that if the arch timer works for you: use the arch
>> timer. If the arch timer doesn't work for you, use the MCT.
>>
>> -Doug
>
> I possess no knowledge if there're any different hw revisions of
> odroid-xu3 on the field
> but looks like arch timer works fine for me on odroid-xu3 Exynos5422
> SoC with upstream kernel.
Well, it looked like it worked for us too. In fact, I never saw a
failure. All I know is that Samsung said: don't do this, it's not a
good idea. The performance gain wasn't enough to go against that...
That's when I started trying to optimize the MCT a little bit. ;)
-Doug
On 07/29/15 08:29, Doug Anderson wrote:
> Hi,
>
Hi,
> On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov <[email protected]> wrote:
>> Hi Doug,
>>
>> On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson <[email protected]> wrote:
>>> Alexey,
>>>
>>> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov <[email protected]> wrote:
>>>> Hi all,
>>>>
>>>> year(s) ago it was discovered that MCT timer and ARM architectured
>>>> timer
>>>> are the same hardware with different interface. Here [1].
>>>>
>>>> I followed mail-list discussions about removing MCT and using arch
>>>> timer for Exynos5-based SoCs but things aren't moving at least latest
>>>> upstream kernel on odroid-xu3 will use MCT as default timers.
>>>> Maybe the reason are some power-management related things that very
>>>> specific to Samsung. I don't know.
>>>>
>>>>
>>>> Idea of this draft patchset comes from Doug patches when he tried to
>>>> optimize read of 64-bit counter located in mmio. [2]
>>>> Why not using cp15 counter instead if possible?
>>>
>>> I hate to burst your bubble here, but...
>>>
>>> ...I think it would be a bad idea to use the cp15 counter on exynos
>>> 5422. According to Samsung, there are issues where using cp15 could
>>> sometimes return the wrong value, especially if you happen to read it
>>> while on an A7 instead of an A15. It will tend to work pretty well,
>>> but Samsung claimed that it might not work right on some CPUs or at
>>> some temperatures.
>>
>> I think this is right time when I can say "If only I had known about
>> it before!".
>
> Yeah, we spent a whole lot of time on this too before giving up after
> we found out it was not possible to use.
>
>
>> That's quite interesting especially about temperature issues.
>> Maybe it's worth to insert comments in driver/docs about this.
>
> Maybe not a bad idea. Depends if you think someone else will try to
> do this... ...and if they do, will they check mailing list traffic.
>
>
>>> Generally I'd say that if the arch timer works for you: use the arch
>>> timer. If the arch timer doesn't work for you, use the MCT.
>>>
One more thing, if you change it for your own private platform, it's up
to you but if not, i.e., for mass product, please don't change it.
Because it's not guaranteed even you haven't seen its failure...
>>> -Doug
>>
>> I possess no knowledge if there're any different hw revisions of
>> odroid-xu3 on the field
>> but looks like arch timer works fine for me on odroid-xu3 Exynos5422
>> SoC with upstream kernel.
>
> Well, it looked like it worked for us too. In fact, I never saw a
> failure. All I know is that Samsung said: don't do this, it's not a
> good idea. The performance gain wasn't enough to go against that...
> That's when I started trying to optimize the MCT a little bit. ;)
>
Yeah and it was tough time for me when I discussed about that with
hardware designer at that time ... haha...
Thanks, Doug.
- Kukjin