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
| ||
|
Date: Mon, 30 Jul 2012 12:31:45 +0000 From: "Bedia, Vaibhav" <vaibhav.bedia@...com> To: Linus Walleij <linus.walleij@...aro.org> CC: Colin Cross <ccross@...roid.com>, Russell King <linux@....linux.org.uk>, Nicolas Pitre <nico@...aro.org>, Marc Zyngier <marc.zyngier@....com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, John Stultz <john.stultz@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Krzysztof Halasa <khc@...waw.pl> Subject: RE: [RFC] ARM: sched_clock: update epoch_cyc on resume On Sat, Jul 28, 2012 at 03:53:05, Linus Walleij wrote: > On Tue, Jul 24, 2012 at 11:16 AM, Bedia, Vaibhav <vaibhav.bedia@...com> wrote: > > >> > A connecting theme is that of being avle to flag clock sources as > >> > sched_clock providers. If all clocksources were tagged with > >> > rating, and only clocksources were used for sched_clock(), the > >> > kernel could select the highest-rated clock under all circumstances. > >> > > >> > But that's quite intrusive, more of an idea. :-P > >> > > > > Too intrusive I guess ;) > > > > There were some discussions on this in the context of AM335x [1] [2]. > > Right now only sched_clock can be registered and I guess this restriction > > is not going to go away any time soon. > > Why do you think that? The restriction to only assign sched_clock() at > compile-time was recently removed so its now runtime assigned. > Yes it's runtime assigned but multiple calls to setup_sched_clock() will trigger a WARN_ON() from arch/arm/kernel/sched_clock.c unless I missing something basic here. > So yes, a clock source that can die and change frequency is no good > as primary system time, but the abstraction could still be used for > those that do, just add another flag NOT_CONTINUOUS or so, and > make sure the system does not select this for primary system > clock source. > > Then modelling sched_clock() on clock sources makes all more > sense: just select the best one. For primary system clock source, > do not select one which is non-continous. > I think what you are suggesting above is similar to what AM335x was trying to do but Russell pointed out issues with switching of timing sources and that's what I was trying to highlight. Regards, Vaibhav B. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists