[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1307051802560.32106@ionos.tec.linutronix.de>
Date: Fri, 5 Jul 2013 18:05:14 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Sören Brinkmann <soren.brinkmann@...inx.com>
cc: John Stultz <john.stultz@...aro.org>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Michal Simek <michal.simek@...inx.com>
Subject: Re: [PATCH] clocksource/cadence_ttc: Reuse clocksource as
sched_clock
On Fri, 5 Jul 2013, Sören Brinkmann wrote:
> On Fri, Jul 05, 2013 at 08:30:47AM +0200, Thomas Gleixner wrote:
> > On Wed, 3 Jul 2013, Soren Brinkmann wrote:
> >
> > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > sched clock is supported in Linux, this feature optional and can be
> > > selected through Kconfig.
> >
> > This changelog doesn't make sense.
> >
> > There can be only one active sched_clock, but that does no mean, that
> > you cannot have different implementations compiled in.
> >
> > So if you disable this config which sched_clock is your kernel using?
> Jiffies
>
> > And if you enable it, how is guaranteed that you end up with the ttc
> > sched_clock as the active one? Just due to initcall ordering?
> I assumed so. Is there a different mechanism?
jiffies is the default one. If you setup an explicit sched clock then
this is used. initcall ordering only matters if you have two possible
sched clocks which might replace jiffies. The one which gets
registered last wins.
So the question is, why you want to disable your sched clock at
compile time.
Thanks,
tglx
Powered by blists - more mailing lists