linux-kernel - Re: [PATCH 1/2 v3] SGI RTC: add clocksource driver

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: <20081121172302.GD12370@sgi.com>
Date:	Fri, 21 Nov 2008 11:23:02 -0600
From:	Dimitri Sivanich <sivanich@....com>
To:	john stultz <johnstul@...ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [PATCH 1/2 v3] SGI RTC: add clocksource driver

John,

Thanks for the reply.  I will address this in forthcoming patchsets.

On Thu, Nov 20, 2008 at 04:08:08PM -0800, john stultz wrote:
> On Thu, 2008-11-20 at 15:08 -0800, Andrew Morton wrote:
> > On Wed, 19 Nov 2008 15:23:50 -0600
> > Dimitri Sivanich <sivanich@....com> wrote:
> > 
> > > This patch provides a driver for SGI RTC clocks and timers.
> > > 
> > > This provides a high resolution clock and timer source using the SGI
> > > system-wide synchronized RTC clock/timer hardware.
> [snip]
> > > +static struct clocksource clocksource_uv = {
> > > +	.name		= RTC_NAME,
> > > +	.rating		= 400,
> > > +	.read		= uv_read_rtc,
> > > +	.mask		= (cycle_t)UVH_RTC_REAL_TIME_CLOCK_MASK,
> > > +	.shift		= 0,
> > > +	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
> > > +};
> 
> Hey Dimitri,
> 	One issue with this clocksource is the shift value. The clocksource
> frequency is calculated from the mult/shift pair (f = mult/2^shift).
> When NTP steers the clock in the generic timekeeping code, it does so by
> tweaking the mult value up or down. However if the shift value is too
> low, that ends up being quite a large change to the frequency.
> 
> So in order to get fine grained frequency adjustments I'd recommend
> using a larger shift value (8 at least). Ideally you want the largest
> shift value possible, but some care is needed that it isn't too big,
> because larger shift values mean larger mult values, and you don't want
> to overflow on the multiplication.
> 
> A rule of thumb I use is to find a shift value so the resulting mult
> value won't overflow 1 second worth of cycles.
> 
--
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/