arm: Replace arm sched_clock by clocksource based sched_clock
Get series with b4
b4 am [email protected]Versions newest first
- 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 files | Size | Replies | Applied |
|---|---|---|---|---|
| 7/16 | arm: omap: Use clocksource based sched_clockarch/ | +0 | 1 reply | |
| 7/16 | arm: omap: Use clocksource based sched_clockarch/ arch/ arch/ +2 more | +13 | 1 reply | |
| 7/16 | arm: omap: Use clocksource based sched_clock | +0 | 0 replies |
Reviews trailers per patch
None of the 3 patches has a Reviewed-by or Acked-by.
| Patch | Tony Lindgren |
|---|---|
| 7/16 | T-b |
| 7/16 | T-b |
| 7/16 | T-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
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_clocksis using the timekeeping clocksource as thesched_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_clockreally needs to be setup earlier than clocksources are setup, beforesched_init()is called ininit/main.c. This is where the scheduler reads the initial value ofsched_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 thesched_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_clockis 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