linux-kernel - Re: [PATCH] RFC: nomadik: expand timesource to 63 bits

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]

Date:	Fri, 12 Nov 2010 14:15:05 -0500 (EST)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	john stultz <johnstul@...ibm.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Rabin Vincent <rabin.vincent@...ricsson.com>,
	linux-kernel@...r.kernel.org, Colin Cross <ccross@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] RFC: nomadik: expand timesource to 63 bits

On Fri, 12 Nov 2010, Uwe Kleine-König wrote:

> On Thu, Nov 11, 2010 at 01:33:41PM -0800, john stultz wrote:
> > Instead, I'd use this extension at the sched_clock level, where it
> > seems reasonable that it will be called frequently enough to not brake
> > the cnt32_to_63 magic.
> Instead of implementing sched_clock for each architecture seperatly,
> wouldn't it be nice to have a generic sched_clock that uses the
> architecture's clocksource?  I tried to implement that some time ago,
> but tglx shoot it down because of locking problems.

They also have different goals.

sched_clock: fast implementation with a moderate 
accuracy.  Used for things like scheduler time slices and printk 
timestamping, and since it is called often it needs to be as lightweight 
as possible and accuracy is secondary.

clocksource: as accurate as possible, used for POSIX timers and the 
like, and is typically more heavyweight than sched_clock().

> Maybe doing that became easier since then?

Maybe having a fallback sched_clock implementation based on clocksource 
might make sense, but the current fallback is based on jiffies which is 
probably good enough as a fallback.

Nicolas