From mboxrd@z Thu Jan 1 00:00:00 1970 From: tglx@linutronix.de (Thomas Gleixner) Date: Fri, 29 Apr 2011 19:01:18 +0200 (CEST) Subject: [patch 00/16] arm: Replace arm sched_clock by clocksource based sched_clock In-Reply-To: <20110429103208.GA2849@atomide.com> References: <20110423205036.795894921@linutronix.de> <20110429094606.GA5126@n2100.arm.linux.org.uk> <20110429103208.GA2849@atomide.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 29 Apr 2011, Tony Lindgren wrote: > * Thomas Gleixner [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