linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4DA6D85A.8000800@wildgooses.com>
Date:	Thu, 14 Apr 2011 12:19:54 +0100
From:	Ed W <lists@...dgooses.com>
To:	johnstul@...ibm.com, linux-kernel@...r.kernel.org
Subject: Improved TSC calculation

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.

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?

Thanks

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