Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1193502 > unrolled thread

[RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit  counter from coprocessor Alexey Klimov <klimov.linux@gmail.com> - 2015-07-27 23:30 +0200
    Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit  counter from coprocessor Kukjin Kim <kgene@kernel.org> - 2015-07-30 16:30 +0200

#1193502 — [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1196076

On 07/29/15 08:29, Doug Anderson wrote:
> Hi,
> 
Hi,

> On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov <klimov.linux@gmail.com> wrote:
>> Hi Doug,
>>
>> On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson <dianders@chromium.org> wrote:
>>> Alexey,
>>>
>>> On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov <klimov.linux@gmail.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web