linux-kernel - Re: [PATCH 6/6] clocksource: tile: convert to use clocksource_register

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: <1306950930.3359.61.camel@work-vm>
Date:	Wed, 01 Jun 2011 10:55:30 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Chris Metcalf <cmetcalf@...era.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6/6] clocksource: tile: convert to use
 clocksource_register_hz

On Wed, 2011-06-01 at 12:18 -0400, Chris Metcalf wrote:
> On 6/1/2011 3:32 AM, John Stultz wrote:
> > From: John Stultz <johnstul@...ibm.com>
> >
> > Convert tile to use clocksource_register_hz.
> >
> > Untested. Help from maintainers would be appreciated.
> >
> > CC: Chris Metcalf <cmetcalf@...era.com>
> 
> This patch boots up fine on tile.  It provides a shift count of 31, with a
> mult value in the billions.  This does mean that clocksource_cyc2ns() will
> only be able to give correct timer conversions for up to about 9 seconds. 
> Is this believed to be adequate for all the uses the cycle counter is put
> to?  I can run our normal regression tests, but I'd like to get a
> high-level sanity check from the clocksource folks.

I believe 9 seconds should be plenty for timekeeping, so I suspect it
should be fine. Although I've not closely checked in this case if the
tile clocksource is used for other purposes, so do let me know if you
see any issues in your testing.

Additionally Thomas has a patch (which I thought already landed in
3.0-rc, but maybe not) which should pick a shift value that gets us
close to 600 second intervals (hardware allowing), allowing for much
longer NOHZ periods.

The important part is that we're centralizing this logic so it can be
properly adjusted without having to tune 30-some clocksources
individually.

Thanks for the testing and review!
-john

--
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/