linux-kernel - Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

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:	Tue, 05 Mar 2013 14:47:27 +0800
From:	John Stultz <john.stultz@...aro.org>
To:	Feng Tang <feng.tang@...el.com>
CC:	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>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	linux-kernel@...r.kernel.org, gong.chen@...ux.intel.com
Subject: Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource
 to count suspended time

On 03/05/2013 02:38 PM, Feng Tang wrote:
> On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:
>
>>
>> So this might be ok for an initial implementation, as on the
>> non-stop-tsc hardware, the TSC is the best clocksource available.
>> One concern long term is that there may be cases where the non-stop
>> clocksource is not the most performant clocksource on a system. In
>> that case, we may want to use a non-stop clocksource that is not the
>> current timekeeping clocksource. So that may require some extra
>> clocksource core interfaces to access the non-stop clocksource
>> instead of using the timekeeper's clocksource, also we'll have to be
>> sure to use something other then cycle_last in that case, since
>> we'll need to read the nonstop clocksource at suspend, rather then
>> trusting that forward_now updates cycle_last as is done here.
> Yeah, I just realized this when Jason mentioned the counter_32k on
> OMAP.
>
> So for next step, we may add something in timekeeping.c like
> 	static struct clocksource *suspend_time_cs;
> read and save its counter righer before entering and after getting
> out of suspended state. And create a new struct which includes
> all time suspend related flags, counters, pointers, make it as a
> member of struct timekeeper. Comments?
I'd maybe add it to the clocksource code rather then the timekeeper. 
Have a clocksource_nonstop_clock() accessor which returns a pointer to 
the highest rated clocksource in the clocksource list that has the 
nonstop flag (updating the pointer at registration time, rather then 
scanning the list every time).

That way if we want, we can later define clocksource_nonstop_clock() as 
null, and let the complier optimize out the extra complexity in the 
resume path if the arch doesn't support nonstop clocksource.

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/