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:	Mon, 22 Mar 2010 12:17:44 +0100
From:	Johannes Weiner <hannes@...xchg.org>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	john stultz <johnstul@...ibm.com>,
	Richard Henderson <rth@...ddle.net>,
	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Matt Turner <mattst88@...il.com>
Subject: Re: [RFC][PATCH] Convert alpha to use clocksource

Hi,

On Fri, Mar 19, 2010 at 12:40:30AM +0300, Ivan Kokshaysky wrote:
> On Thu, Mar 18, 2010 at 10:55:23AM -0700, john stultz wrote:
> > On Thu, 2010-03-18 at 07:32 -0700, Richard Henderson wrote:
> > > On 03/17/2010 07:01 PM, John Stultz wrote:
> > > > Alpha has a tsc like rpcc counter that it uses to manage time.
> > > > This can be converted to an actual clocksource instead of utilizing
> > > > the arch_gettimeoffset method that is really only there for legacy
> > > > systems with no continuous counter.
> > > 
> > > With 8 seconds or less between roll-overs, do you actually consider
> > > this a continuous counter?  I don't.  I suggest this be left alone.
> > 
> > The timekeeping code handles this (although the shift value I picked may
> > need some adjustment - what is the expected counter freq range on
> > alpha?). The ACPI PM counter which is very common on x86 is only 24 bits
> > and rolls over in ~5 seconds. It works fine.
> 
> Yeah, that looks cool. I'm typing this on the 800MHz UP1500 running
> 2.6.34-rc1 plus your patch, and the timekeeping works fine so far.
> 
> Though, even after a glance over the clocksource code, I've not
> gotten yet to how one could estimate the "shift" value...
> Any hints?

I had the same problem with xtensa and added a comment about what I
did in there, maybe it helps:

	arch/xtensa/kernel/time.c

I took the upper bound of the multiplicator (nsecs per counter unit)
and subtracted its logarithm from my available 32 bits.  The result
is the highest possible shift value that works for the clocksource.

	HTH, Hannes
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ