linux-kernel - Re: Improved TSC calculation

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Apr 2011 11:20:53 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Ed W <lists@...dgooses.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Improved TSC calculation

On Thu, 2011-04-14 at 12:19 +0100, Ed W wrote:
> Hi, Thanks for the new stable TSC calculation commit
> (08ec0c58fb8a05d3191d5cb6f5d6f81adb419798).
> 
> My situation is that I don't have a PM or HPET timer (x86 Alix board),
> and my requirements are embedded type use, but with only intermittently
> connected network/gps, so accurate timekeeping between reboots is
> important.
> 
> I had been experimenting with extending the existing PIT timer routines
> at boot, but I had the problem that it was taking 1s+ to get a very
> stable calculation (which is undesirable for my requirements), however,
> having spotted your commit it seems like a much more sensible solution.

Thanks!

> Before I try and hack probably an (inadequate) solution myself, do you
> have any thoughts on the best solution to extend your commit to non
> PM/HEPT machine?  My initial thought was to repeatedly call
> pit_calibrate_tsc() with an extended latch, looking for a stable
> solution (ie refactor native_calibrate_tsc() ).  Is this workable?
> Better ideas?

Oof. So with the PIT you can maybe utilize the second channel/counter,
using a largish long countdown to try to get a similar functionality.
The only big concern is that the timer interrupt hardware is always
problematic (every time we chanage our usage, some random chunk of
laptops seem to stop working). So whatever solution that works for you
might not be able to be generically deployed. But I think it could be
interesting and might be worth you giving it a shot.

I'd probably look at reworking tsc_refine_calibration_work, extending
the tsc_read_refs() code to also get PIT count values and then start the
long PIT countdown on the second channel before we
schedule_delayed_work.

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