linux-kernel - Re: [PATCH] clocksource: shift helper

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1210265327.17132.275.camel@localhost.localdomain>
Date:	Thu, 08 May 2008 09:48:46 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	akpm@...ux-foundation.org, johnstul@...ibm.com,
	ralf@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clocksource: shift helper


On Wed, 2008-05-07 at 05:57 +0200, Roman Zippel wrote:
> Hi,
> 
> On Thursday 1. May 2008, Daniel Walker wrote:
> 
> > This is a little helper I pulled from the mips tree. I've seen a couple
> > of bogus shift values, and this helper calculates the shift. This
> > should move the shift selection away from the user, and systematically
> > pick the value base on the hz.
> >
> > I also modified the acpi_pm timer to use this new interface. The original
> > shift was 22 , and after this patch it's increased to 23. Which should make
> > the clocksource slightly more accurate, but shouldn't have much of a
> > visible effect.
> 
> What is this calculation based on?

It's based on the clocksource_hz2mult() calculation. It tests multiple
shifts until the largest workable one is found.

> Unless I miss something even 22 is far more than enough. acpi_pm has a 
> resolution of 279ns, thus the clock can't be more accurate than half of this 
> on average and increasing the shift doesn't change much directly about it.
> What the shift value does influence is the size of the adjustment step the 
> clock code can do during an update, so with shift=22 and HZ=100 the possible 
> adjustment step would be 0.008ns (freq/2^shift/ntp_hz). The problem is that 
> this value is also used for how soon the clock is being adjusted, this means 
> the clock code is constantly busy adjusting for a very small error.
> So from a clock adjustment perspective a shift value close to log2
> (freq/res/10^9/ntp_hz) (with res=1/freq and being limited to 1ns<=res<=1us) 
> would provide sufficient accuracy, while keeping the need for adjustment low, 
> this means with the above example a shift value of much more than 8 doesn't 
> improve accuracy significantly.

This seems like a problem with the current method also.. Given that
people just "select" a shift, they could pick one that is too large or
too small easily. 

The method in this patch is not very sophisticated, so we could make it
take more into account.

Daniel


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