From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: dts: exynos5: Remove multi core timer
Date: Fri, 16 May 2014 01:25:22 +0200 [thread overview]
Message-ID: <53754CE2.3000905@gmail.com> (raw)
In-Reply-To: <CAASgrz2Nr69tpfC8ka9gbs2OvjLEGsvgAj4vBCFxhsamuFum7w@mail.gmail.com>
On 16.05.2014 01:18, David Riley wrote:
> On Thu, May 15, 2014 at 4:03 PM, Chirantan Ekbote
> <chirantan@chromium.org> wrote:
>> Hi Tomasz,
>>
>> On Thu, May 15, 2014 at 3:44 PM, Doug Anderson <dianders@chromium.org> wrote:
>>> Tomasz,
>>>
>>> On Thu, May 15, 2014 at 3:13 PM, Tomasz Figa <tomasz.figa@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?
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.
Best regards,
Tomasz
next prev parent reply other threads:[~2014-05-15 23:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 21:07 [PATCH] arm: dts: exynos5: Remove multi core timer Chirantan Ekbote
2014-05-15 21:14 ` Tomasz Figa
2014-05-15 21:33 ` Doug Anderson
2014-05-15 21:40 ` Tomasz Figa
2014-05-15 21:54 ` Doug Anderson
2014-05-15 22:13 ` Tomasz Figa
2014-05-15 22:44 ` Doug Anderson
2014-05-15 23:03 ` Chirantan Ekbote
2014-05-15 23:18 ` David Riley
2014-05-15 23:25 ` Tomasz Figa [this message]
2014-05-15 23:39 ` Olof Johansson
2014-05-15 23:45 ` Doug Anderson
2014-05-15 23:46 ` Tomasz Figa
2014-05-15 23:43 ` Doug Anderson
2014-05-16 0:31 ` Sonny Rao
2014-05-16 22:56 ` Chirantan Ekbote
2014-05-17 0:02 ` Kukjin Kim
2014-05-19 15:12 ` Doug Anderson
2014-05-21 13:24 ` Kukjin Kim
2014-05-21 15:30 ` Olof Johansson
2014-05-21 16:20 ` Tomasz Figa
2014-05-21 18:34 ` Chirantan Ekbote
2014-05-28 17:38 ` Doug Anderson
2014-06-02 23:22 ` Doug Anderson
2014-05-21 12:47 ` Kukjin Kim
2014-05-21 18:34 ` Chirantan Ekbote
2014-05-28 17:23 ` Doug Anderson
2014-06-03 18:41 ` Chirantan Ekbote
2014-06-04 1:45 ` Kukjin Kim
2014-05-28 17:37 ` Doug Anderson
2014-05-29 20:42 ` Vincent Guittot
2014-05-29 21:41 ` Doug Anderson
2014-05-15 21:44 ` Kukjin Kim
2014-05-15 21:44 ` Tomasz Figa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53754CE2.3000905@gmail.com \
--to=tomasz.figa@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).