linux-kernel - Re: [PATCH 1/2] time: allow changing the timekeeper clock frequency

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] [day] [month] [year] [list]

Message-ID: <5220C2A2.1020502@linaro.org>
Date:	Fri, 30 Aug 2013 09:04:50 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Chris Metcalf <cmetcalf@...era.com>
CC:	lkml <linux-kernel@...r.kernel.org>, cpufreq@...r.kernel.org,
	Linux PM list <linux-pm@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH 1/2] time: allow changing the timekeeper clock frequency

On 08/30/2013 07:40 AM, Chris Metcalf wrote:
> On 8/29/2013 3:30 PM, John Stultz wrote:
>> On 08/29/2013 11:40 AM, Chris Metcalf wrote:
>>> Ping!  I have this work queued up to push as part of the linux-tile tree for the
>>> merge window.  Is that acceptable to the timekeeping/clocksource folks?
>>> Should I hold it back pending further review?  Or does it make sense to
>>> push it as-is and think about further improvements, if any, for a later release?
>>>
>>> https://lkml.org/lkml/2013/8/9/497
>>> https://lkml.org/lkml/2013/8/9/499
>> Oh right! Sorry for the slow response here! I originally replied while I
>> was on vacation and didn't flag the thread to follow up on.
>>
>> Few comments below.
> Thanks for the feedback. It does sound like too much to take on before
> the 3.12 merge window opens, so we will plan to look into this as time
> permits over the next little while. I've filed a bug internally to
> track this for us.
>
> It sounds like the most straightforward thing for us to do may be to adopt
> your original approach of making our clocksource driver internally convert
> the variable frequency clocksource to a fixed frequency; the overhead
> shouldn't be too bad and it seems like it should moot all the other
> concerns you raised in your email.
Yea, so most of my concerns would also apply to having the clocksource
driver hide the frequency changes (since there still will be latency
error, and variable freq error), but I do prefer having it as a
clocksource specific hack, rather then in the timekeeping core so we can
avoid seemingly condoning wide use of freq changing clocksources. If it
does go in the core, I'm sure a few years down the line, someone will
notice a problem with their freq changing clocksource and demand the
bugs be fixed!

That said, I'm still open to further discussing your current approach
for the next cycle. Since its possible the latency and freq errors
really are small enough to not matter, avoiding the inefficiencies of
hiding the changes in the clocksource driver might be worth it.

thanks
-john

--
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/