[PATCH] arm: dts: exynos5: Remove multi core timer

[Doug Anderson]

Olof,

On Thu, May 15, 2014 at 4:39 PM, Olof Johansson <olof at lixom.net> wrote:
> On Thu, May 15, 2014 at 4:25 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
>> On 16.05.2014 01:18, David Riley wrote:
>>> On Thu, May 15, 2014 at 4:03 PM, Chirantan Ekbote
>>> <chirantan at chromium.org> wrote:
>>>> Hi Tomasz,
>>>>
>>>> On Thu, May 15, 2014 at 3:44 PM, Doug Anderson <dianders at chromium.org> wrote:
>>>>> Tomasz,
>>>>>
>>>>> On Thu, May 15, 2014 at 3:13 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
>>>>>>> NOTE: if for some reason we need to keep the MCT around, we're
>>>>>>> definitely going to need to account for the fact that tweaking it
>>>>>>> affects the arch timer.  ...and having the arch timer is really nice
>>>>>>> since:
>>>>>>
>>>>>> [Let me reorder the points below to make it easier to comment:]
>>>>>>
>>>>>>> * it's faster to access.
>>>>>>> * it is accessible from userspace for really fast access.
>>>>>>
>>>>>> Do you have some data on whether it is a significant difference,
>>>>>> especially considering real use cases?
>>>>>
>>>>> I know that Chrome makes _a lot_ of calls to gettimeofday() for
>>>>> profiling purposes, enough that it showed up on benchmarks.  In fact,
>>>>> we made a change to the MCT to make accesses faster and there's a
>>>>> small mention of the benchmarking that was done at:
>>>>>
>>>>> https://chromium-review.googlesource.com/#/c/32190/
>>>>>
>>>>> ...that change probably should be sent upstream, actually.
>>>>>
>>>>> I'll let Chirantan comment on how much faster arch timers were.
>>>>> ...and I think David Riley (also CCed now) may be able to comment on
>>>>> the benefits of userspace timers.
>>>>>
>>>>
>>>> When I profiled gettimeofday() calls, they were about 50 - 60% faster
>>>> with the arch timers compared to the mct.
>>>
>>> When I profiled gettimeofday(), the standard systems call version took
>>> about 2.5x longer than through a vDSO interface.
>>
>> Sounds like we should invent a new kind of jokes, starting with "When I
>> profiled gettimeofday()". ;)
>>
>> Just kidding.
>>
>> The raw improvement looks quite good, but what I'm more concerned about
>> is whether this has any significant effect on real use cases. As Doug
>> mentioned, Chrome makes a lot of calls to gettimeofday(), but he also
>> mentioned that this is for profiling purposes. Is performance of
>> gettimeofday() really that crucial in this case? Are there any other use
>> cases when this improvement is significant?
>
> In general, yes. gettimeofday() is normally the prime candidate for
> vDSO implementaiton (see Nathan Lynch's patch set in the last couple
> of months for enabling this). Speeding up gettimeofday() does have
> real benefit for some workloads.
>
>> Anyway, I'm by no means opposed to switching to arch timers. They
>> provide a well designed, generic interface and drivers shared by
>> multiple platforms, which means more code sharing and possibly more eyes
>> looking at the code, which is always good. However if they don't support
>> low power states correctly, we can't just remove MCT.
>
> Yeah, this will definitely need to be tested. Do the low power states
> work on exynos5 upstream such that they can be tested? The snow
> chromebook has a u-boot bug that makes AFTR not work, so it's not a
> suitable platform to test on, unfortunately.

As long as you don't have read-only firmware 90.0 then the known bug
is fixed.  If you have 90.0 it's pretty easy to pull our your write
protect screw and update your read-only firmware if you're doing
development.

...but of course it's never been tested, so there might be other bugs.
 The known bug that was fixed was found solely by code inspection (a
missing break statement in a switch).