linux-kernel - Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC

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:	Mon, 25 Mar 2013 16:28:10 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Mark Rutland <mark.rutland@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Magnus Damm <magnus.damm@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Simon Horman <horms@...ge.net.au>,
	John Stultz <john.stultz@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

On 03/25/2013 12:26 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 21, 2013 at 11:06:47AM +0000, Mark Rutland wrote:
>> On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
>> in preference to the architected timer:
>>
>>   Architected local timer running at 24.00MHz (virt).
>>   Switching to timer-based delay loop
>>   Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
>>   sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
>>   Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
>>
>> As they both have the same frequency, neither overrides the other, and
>> whichever gets registered last is used as the sched_clock. As accesses
>> to the architected timer are going to have a much lower overhead, this
>> isn't very nice (and it could be better to use it even if it had a lower
>> frequency).
> 
> I'll remind people that sched_clock() is supposed to be functional at
> the point in the boot sequence where the call to sched_init() is called.
> That is after setup_arch() and *before* time_init() is called.

I count integrator-cp, realview, versatile and non-DT VExpress that do
this (not surprisingly) and 25 platforms or timer implementations plus
arm64 that do sched_clock setup in time_init. What's broken by not
moving these earlier?

We could probably fix arch timers relatively easily, but supporting the
numerous memory-mapped timers will be harder. Most timers are also
dependent on the clocks being initialized. That's really an orthogonal
issue to what this patch series solves. This series is about selecting
the best sched_clock when multiple timers are present. Perhaps one that
is setup in init_early should be preferred over one setup in init_time.
I'm not sure how to detect that.

Rob

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