Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksourceto count suspended time

[John Stultz]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/