[patch 00/16] arm: Replace arm sched_clock by clocksource based sched_clock

Thomas Gleixner
2011-04-29T17:01:18Z

On Fri, 29 Apr 2011, Tony Lindgren wrote:
> * Thomas Gleixner <tglx@linutronix.de> [110429 13:19]:
> > On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
> >
> > > On Sat, Apr 23, 2011 at 08:54:39PM -0000, Thomas Gleixner wrote:
> > > > 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.
> > >
> > > 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.
> >
> > 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.

Right, but where is the problem ? A few time stamps with jiffies
resolution and then the finegrained ones.

Thanks,

tglx