linux-kernel - Re: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1307051819530.32106@ionos.tec.linutronix.de>
Date:	Fri, 5 Jul 2013 18:23:19 +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 06:05:14PM +0200, Thomas Gleixner wrote:
> > 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.
> The timer drivers I have seen unconditionally register themselves as
> sched_clock. There does not seem to be a runtime mechanism to choose the
> best one - I might miss it though.
> I was thinking about this due to the arm_global_timer driver which has
> been dicussed on lkml recently, which seemed to do it this way too. And since
> that timer would be an alternative sched_clock for Zynq too, I thought I
> follow the same approach for the TTC.

Hmm, ok. So there is a generic one as well. If we end up with multiple
choices for that sched_clock, then there should be a mechanism to
avoid that #ifdeffery and have it runtime selected.

Having a setup call with a rating argument would be a first step. So
the one with the highest rating wins. If people want to have it
selectable from the kernel commandline, it would need some string
matching as well.

Thanks,

	tglx