Skip to content

arm: Replace arm sched_clock by clocksource based sched_clock

Tony Lindgren linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest3 of 16 patches 0 repliesNew

3 of 16 patches are in this archive. The cover letter announces 16.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
7/16arm: omap: Use clocksource based sched_clockarch/arm/plat-omap/counter_32k.c+0 -21 reply
7/16arm: omap: Use clocksource based sched_clockarch/arm/mach-omap1/time.c arch/arm/mach-omap2/timer-gp.c arch/arm/plat-omap/counter_32k.c +2 more+13 -1341 reply
7/16arm: omap: Use clocksource based sched_clock+0 -00 replies

Reviews trailers per patch

None of the 3 patches has a Reviewed-by or Acked-by.

PatchTony Lindgren
7/16T-b
7/16T-b
7/16T-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [patch 00/16] arm: Replace arm sched_clock by clocksource based sched_clock
Quoted 25 lines · Thomas Gleixner
Quoted 10 lines · Russell King - ARM Linux
Quoted 3 lines · Thomas Gleixner

Most of ARM sched_clocks is using the timekeeping clocksource as the sched_clock. Only versatile uses a different clock for it, but there is no real reason why it can't use the clocksource as well.

sched_clock really needs to be setup earlier than clocksources are setup, before sched_init() is called in init/main.c. This is where the scheduler reads the initial value of sched_clock() to start its time measurements. This is well before clocksources are initialized, or even the irq subsystem.

Quoted 4 lines

So I don't believe bolting it directly into the clocksource code in this way is correct. As things are currently setup with my sched_clock() implementation, we can (and in any cases do) get the sched_clock() up and running really early which is what's required.

Not really. There is no requirement to have a high resolution sched clock in the early boot process. The only requirement is that sched_clock is monotonic increasing nsecs. So the code utilizes jiffies up to the point where the clocksource is installed and then switches over keeping the clock monotonic. The scheduler does not care whether it gets coarse grained time information in the early boot stage and then fine grained information at some point later.

Quoted 3 lines

The only drawback is that you don't get precise timestamps for tracing up to the point where the clock source is installed. But that's really not a big deal to worry about.

What about PRINTK_TIME? I think that uses sched_clock right from the start.

Tony