linux-kernel - Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.

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, 01 Apr 2013 10:32:30 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Pavel Machek <pavel@....cz>
CC:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Feng Tang <feng.tang@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...ux.intel.com>, x86@...nel.org,
	Len Brown <lenb@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.

On 03/30/2013 11:14 AM, Pavel Machek wrote:
> Hi!
>
>>> On some new Intel Atom processors (Penwell and Cloverview), there is
>>> a feature that the TSC won't stop S3, say the TSC value won't be
>>> reset to 0 after resume. This feature makes TSC a more reliable
>>> clocksource and could benefit the timekeeping code during system
>>> suspend/resume cycles.
>>>
>>> The enabling efforts include adding new flags for this feature,
>>> modifying clocksource.c and timekeeping.c to support and utilizing
>>> it.
>>>
>>> One remaining question is inside the timekeeping_resume(), we don't
>>> know if it is called by resuming from suspend(s2ram) or from
>>> hibernate(s2disk), as there is no easy way to check it currently.
>>> But it doesn't hurt as these Penwell/Cloverview platforms only have
>>> S3 state, and no S4.
>>>
>>> Please help to review them, thanks!
>> The patches look reasonable to me.
> Not sure... what are advantages? TSC is high resolution, but not
> exactly precise time source... and this only makes resume more
> complex.
Providing sub-second granularity for suspend time measurement is a 
pretty compelling use, which greatly reduces time error across 
suspend/resume.

I agree that the code logic is more complex, but the TSC path should be 
a good bit faster then hitting the CMOS.
And overall, I'm hoping we can eventually move the RTC based 
read_persistent_clock() implementations into the rtc core, then allow 
for clocksource based suspend timing where available (since ARM boards 
are already basically doing this, but hiding it behind 
read_persistent_clock() calls).

There is the open concern that given their history, x86 designers will 
find yet another way to break the TSC in some future chip and we'll end 
up with non-stop TSCs that run at different frequencies in suspend or 
some other such nonsense. But we'll just have to detect that and disable 
functionality where appropriate, much as we do with the TSC now.

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/