linux-kernel - Re: [PATCH 2/3] clocksource: exynos

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Jun 2014 10:14:05 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	Kukjin Kim <kgene.kim@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Chirantan Ekbote <chirantan@...omium.org>,
	David Riley <davidriley@...omium.org>,
	Olof Johansson <olof@...om.net>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Mandeep Singh Baines <msb@...omium.org>,
	Andrew Bresticker <abrestic@...omium.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	LAK <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/3] clocksource: exynos_mct: cache mct upper count

Vincent,

On Thu, Jun 5, 2014 at 12:55 AM, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> On 4 June 2014 19:30, Doug Anderson <dianders@...omium.org> wrote:
>> From: Mandeep Singh Baines <msb@...omium.org>
>>
>> Saves one register read.  Note that the upper count only changes every
>> ~178 seconds with a 24MHz source clock, so it's likely it hasn't
>> changed from call to call.
>
> Hi Doug,
>
> Have you checked that the time saved in using a 32bits counter instead
> of a 64bits one is not lost in the handle of the wrap of sched_clock
> which occurs every 178s instead of never ?
>
> sched_clock_poll function will be called every 178s

Probably should move this to the discussion in the other patch where
we're talking about moving to 32-bits?

...but in general I have no benchmarks at all that how much the
scheduler is affected by this change.  All of my benchmarks are based
on gettimeofday(), where the improvement is clear.  Do you have a
suggested way to check?

I think that it's pretty clear that we'll want to take either the
32-bit conversion or the 64-bit optimizations I sent out.  If you take
out gettimeofday() overhead, I believe that the actual read of the MCT
(exynos_frc_read) took about:
* ~800ns per call with the original 64-bit code
* ~500ns per call with the optimized 64-bit code (both patch 2 and 3)
* ~500ns per call with the 32-bit code

The 32-bit code is slightly faster but not significantly (like 530ns
vs 500ns).  ...but it is definitely simpler.

If we find that the schedule clock wrap overhead is real then that
would be a good reason to take the 64-bit version.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/