Architecture specific implementations for tickless kernel and deferrable timers

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

Hi,

I am developing a BSP for a ARM Cortex-M3 (no MMU) based board. In
order to have tickless kernel and deferrable timers, what are the
architecture specific implementations. Can some one point out some
examples that already have this feature enabled and also in the kernel
tree.

And also, are clocksoure and clockevents dependent on each other? I
see in some platforms, that they have used 2 different timers for the
above. Can a same clock be used for both clocksource and clockevents?
Please throw some light on this. If it can be used so, what ties up
the clocksource and clockevent?

NOTE: As cortex-M3 doesn't have an MMU I should be using uClinux.
Since my question is very much relevant to ARM I am posting it here.

-
Vikram

Architecture specific implementations for tickless kernel and deferrable timers

[Jeff Ohlstein]

Vikram Narayanan wrote:
> And also, are clocksoure and clockevents dependent on each other? I
> see in some platforms, that they have used 2 different timers for the
> above. Can a same clock be used for both clocksource and clockevents?
> Please throw some light on this. If it can be used so, what ties up
> the clocksource and clockevent?

You can look at msm for an example of a single timer being used both as
a clocksource and a clockevent. We end up shutting off the clocksource
whenever we shut down the clockevent. This does cause some issues.
Switching clocksources at runtime does not work. It will also cause
problems if you implement your own sched_clock function, as it will have
little choice but to return a stale cached value whenever the clockevent
is disabled, such as in the suspend path.

Jeff

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Fri, Apr 22, 2011 at 8:43 AM, Jeff Ohlstein <johlstei@codeaurora.org> wrote:
> Vikram Narayanan wrote:
>> And also, are clocksoure and clockevents dependent on each other? I
>> see in some platforms, that they have used 2 different timers for the
>> above. Can a same clock be used for both clocksource and clockevents?
>> Please throw some light on this. If it can be used so, what ties up
>> the clocksource and clockevent?
>
> You can look at msm for an example of a single timer being used both as
> a clocksource and a clockevent. We end up shutting off the clocksource
> whenever we shut down the clockevent. This does cause some issues.
> Switching clocksources at runtime does not work. It will also cause
> problems if you implement your own sched_clock function, as it will have
> little choice but to return a stale cached value whenever the clockevent
> is disabled, such as in the suspend path.
Thanks for the example. I will refer to that. And I have another
question, If dynamic ticks are implemented, say if I am using the same
clocksource and clockevent, the wall time will only be updated at that
dyn_tick interval. Will that create any issue? or should I use a
constant source for the clocksource? or how to handle this in an
effective way.
* Clocksource and clockevents with the same timer.
* Also I want to make use of the tickless kernel functionality.

Vikram

>
> Jeff
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>

Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Sun, Apr 24, 2011 at 07:50:55PM +0530, Vikram Narayanan wrote:
> On Fri, Apr 22, 2011 at 8:43 AM, Jeff Ohlstein <johlstei@codeaurora.org> wrote:
> > Vikram Narayanan wrote:
> >> And also, are clocksoure and clockevents dependent on each other? I
> >> see in some platforms, that they have used 2 different timers for the
> >> above. Can a same clock be used for both clocksource and clockevents?
> >> Please throw some light on this. If it can be used so, what ties up
> >> the clocksource and clockevent?
> >
> > You can look at msm for an example of a single timer being used both as
> > a clocksource and a clockevent. We end up shutting off the clocksource
> > whenever we shut down the clockevent. This does cause some issues.
> > Switching clocksources at runtime does not work. It will also cause
> > problems if you implement your own sched_clock function, as it will have
> > little choice but to return a stale cached value whenever the clockevent
> > is disabled, such as in the suspend path.
> Thanks for the example. I will refer to that. And I have another
> question, If dynamic ticks are implemented, say if I am using the same
> clocksource and clockevent, the wall time will only be updated at that
> dyn_tick interval. Will that create any issue? or should I use a
> constant source for the clocksource? or how to handle this in an
> effective way.
> * Clocksource and clockevents with the same timer.
> * Also I want to make use of the tickless kernel functionality.

The only way to have a stable time source is to have a stable clocksource
- one which is never stopped or otherwise messed around with.  If you
try to combine clocksource and clockevent with one-shot mode, where
the clocksource part is reset each time a new event is set, you'll probably
soon end up with time going screwy.

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Wed, Apr 27, 2011 at 2:07 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Apr 24, 2011 at 07:50:55PM +0530, Vikram Narayanan wrote:
>> On Fri, Apr 22, 2011 at 8:43 AM, Jeff Ohlstein <johlstei@codeaurora.org> wrote:
>> > Vikram Narayanan wrote:
>> >> And also, are clocksoure and clockevents dependent on each other? I
>> >> see in some platforms, that they have used 2 different timers for the
>> >> above. Can a same clock be used for both clocksource and clockevents?
>> >> Please throw some light on this. If it can be used so, what ties up
>> >> the clocksource and clockevent?
>> >
>> > You can look at msm for an example of a single timer being used both as
>> > a clocksource and a clockevent. We end up shutting off the clocksource
>> > whenever we shut down the clockevent. This does cause some issues.
>> > Switching clocksources at runtime does not work. It will also cause
>> > problems if you implement your own sched_clock function, as it will have
>> > little choice but to return a stale cached value whenever the clockevent
>> > is disabled, such as in the suspend path.
>> Thanks for the example. I will refer to that. And I have another
>> question, If dynamic ticks are implemented, say if I am using the same
>> clocksource and clockevent, the wall time will only be updated at that
>> dyn_tick interval. Will that create any issue? or should I use a
>> constant source for the clocksource? or how to handle this in an
>> effective way.
>> * Clocksource and clockevents with the same timer.
>> * Also I want to make use of the tickless kernel functionality.
>
> The only way to have a stable time source is to have a stable clocksource
> - one which is never stopped or otherwise messed around with. ?If you
> try to combine clocksource and clockevent with one-shot mode, where
> the clocksource part is reset each time a new event is set, you'll probably
> soon end up with time going screwy.
>
Thanks for the insight.
My another question is that, where can I find some examples of dynamic
tick implementation. Are there any documents for implementing the
functionality?
Also the struct dyn_tick_timer in the file include/asm-arm/mach/time.h
is removed since 2.6.27. So how do I achieve this?
If you refer me to some documentation on this, that would be great.

-
Thanks
Vikram

Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Wed, Apr 27, 2011 at 09:00:54AM +0530, Vikram Narayanan wrote:
> My another question is that, where can I find some examples of dynamic
> tick implementation. Are there any documents for implementing the
> functionality?

Dynamic tick was obsoleted by NO_HZ.  The kernel now contains NO_HZ which
relies upon the one-shot clock event mode.

Architecture specific implementations for tickless kernel and deferrable timers

[Thomas Gleixner]

On Wed, 27 Apr 2011, Vikram Narayanan wrote:
> On Wed, Apr 27, 2011 at 2:07 AM, Russell King - ARM Linux
> > The only way to have a stable time source is to have a stable clocksource
> > - one which is never stopped or otherwise messed around with. ?If you
> > try to combine clocksource and clockevent with one-shot mode, where
> > the clocksource part is reset each time a new event is set, you'll probably
> > soon end up with time going screwy.
> >
> Thanks for the insight.
> My another question is that, where can I find some examples of dynamic
> tick implementation. Are there any documents for implementing the
> functionality?
> Also the struct dyn_tick_timer in the file include/asm-arm/mach/time.h
> is removed since 2.6.27. So how do I achieve this?
> If you refer me to some documentation on this, that would be great.

Provide a functional clocksource plus a clockevent device which is
oneshot capable. Enable CONFIG_NOHZ and there you go.

Thanks,

	tglx

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Wed, Apr 27, 2011 at 1:47 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 27 Apr 2011, Vikram Narayanan wrote:
>> On Wed, Apr 27, 2011 at 2:07 AM, Russell King - ARM Linux
>> > The only way to have a stable time source is to have a stable clocksource
>> > - one which is never stopped or otherwise messed around with. ?If you
>> > try to combine clocksource and clockevent with one-shot mode, where
>> > the clocksource part is reset each time a new event is set, you'll probably
>> > soon end up with time going screwy.
>> >
>> Thanks for the insight.
>> My another question is that, where can I find some examples of dynamic
>> tick implementation. Are there any documents for implementing the
>> functionality?
>> Also the struct dyn_tick_timer in the file include/asm-arm/mach/time.h
>> is removed since 2.6.27. So how do I achieve this?
>> If you refer me to some documentation on this, that would be great.
>
> Provide a functional clocksource plus a clockevent device which is
> oneshot capable. Enable CONFIG_NOHZ and there you go.
>
I am still confused about the terms clocksource and clockevents. Can
someone please explain it in simple terms or lead me to a good
documentation that elaborates clearly about this?

Thanks,
Vikram
> Thanks,
>
> ? ? ? ?tglx

Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 07:01:53PM +0530, Vikram Narayanan wrote:
> On Wed, Apr 27, 2011 at 1:47 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Wed, 27 Apr 2011, Vikram Narayanan wrote:
> >> On Wed, Apr 27, 2011 at 2:07 AM, Russell King - ARM Linux
> >> > The only way to have a stable time source is to have a stable clocksource
> >> > - one which is never stopped or otherwise messed around with. ?If you
> >> > try to combine clocksource and clockevent with one-shot mode, where
> >> > the clocksource part is reset each time a new event is set, you'll probably
> >> > soon end up with time going screwy.
> >> >
> >> Thanks for the insight.
> >> My another question is that, where can I find some examples of dynamic
> >> tick implementation. Are there any documents for implementing the
> >> functionality?
> >> Also the struct dyn_tick_timer in the file include/asm-arm/mach/time.h
> >> is removed since 2.6.27. So how do I achieve this?
> >> If you refer me to some documentation on this, that would be great.
> >
> > Provide a functional clocksource plus a clockevent device which is
> > oneshot capable. Enable CONFIG_NOHZ and there you go.
> >
> I am still confused about the terms clocksource and clockevents. Can
> someone please explain it in simple terms or lead me to a good
> documentation that elaborates clearly about this?

A clocksource is a monotonically incrementing counter which measures the
passing of time.  This counter should never be reset.

A clockevent device is some sort of timer which it used to trigger either
a periodic interrupt or a one-shot interrupt to cause CPUs to do some
maintainence task (such as reading the clock source, comparing that with
the previous reading, and using the delta to update the kernels idea of
current time.)

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Thu, Apr 28, 2011 at 7:08 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Apr 28, 2011 at 07:01:53PM +0530, Vikram Narayanan wrote:
>> On Wed, Apr 27, 2011 at 1:47 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Wed, 27 Apr 2011, Vikram Narayanan wrote:
>> >> On Wed, Apr 27, 2011 at 2:07 AM, Russell King - ARM Linux
>> >> > The only way to have a stable time source is to have a stable clocksource
>> >> > - one which is never stopped or otherwise messed around with. ?If you
>> >> > try to combine clocksource and clockevent with one-shot mode, where
>> >> > the clocksource part is reset each time a new event is set, you'll probably
>> >> > soon end up with time going screwy.
>> >> >
>> >> Thanks for the insight.
>> >> My another question is that, where can I find some examples of dynamic
>> >> tick implementation. Are there any documents for implementing the
>> >> functionality?
>> >> Also the struct dyn_tick_timer in the file include/asm-arm/mach/time.h
>> >> is removed since 2.6.27. So how do I achieve this?
>> >> If you refer me to some documentation on this, that would be great.
>> >
>> > Provide a functional clocksource plus a clockevent device which is
>> > oneshot capable. Enable CONFIG_NOHZ and there you go.
>> >
>> I am still confused about the terms clocksource and clockevents. Can
>> someone please explain it in simple terms or lead me to a good
>> documentation that elaborates clearly about this?
>
> A clocksource is a monotonically incrementing counter which measures the
> passing of time.
So, this is the timer that keeps the wall time always up as long as
the system is running. If the system isn't running, a backup RTC
should take care of the time. When the system is back, again
clocksource will be having the control.
Even if the above timer count overflows, that should be taken care of.
> This counter should never be reset.
So this timer should always be on, no matter what happens to the system.
>
> A clockevent device is some sort of timer which it used to trigger either
> a periodic interrupt or a one-shot interrupt to cause CPUs to do some
> maintainence task (such as reading the clock source, comparing that with
> the previous reading, and using the delta to update the kernels idea of
> current time.)
This is used for setting up the next event by using the set_next_event
callback and set the mode(one shot or periodic) by set_mode callback.
So, this timer is the heart of tickless kernel functionality(NO_HZ).

These are my understandings, correct me if I am wrong.

If my understandings are right, it would be a very bad idea to use the
same timer for clocksource and clockevent device, as the clockevent
device may alter the counter value of clocksource.

Thanks for the quick response,
Vikram

Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 07:24:41PM +0530, Vikram Narayanan wrote:
> On Thu, Apr 28, 2011 at 7:08 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Apr 28, 2011 at 07:01:53PM +0530, Vikram Narayanan wrote:
> >> I am still confused about the terms clocksource and clockevents. Can
> >> someone please explain it in simple terms or lead me to a good
> >> documentation that elaborates clearly about this?
> >
> > A clocksource is a monotonically incrementing counter which measures the
> > passing of time.
>
> So, this is the timer that keeps the wall time always up as long as
> the system is running. If the system isn't running, a backup RTC
> should take care of the time. When the system is back, again
> clocksource will be having the control.
> Even if the above timer count overflows, that should be taken care of.

What basically happens is:

	now = cs->read(cs);
	delta = (now - cs->cycle_last) & cs->mask;
	cs->cycle_last = now;

	ns = clocksource_cyc2ns(delta, cs...);

ns now represents the amount of time which passed between this read and
the previous read.  Note the mask in the calculation of delta ensures
that overflows are taken care of.

> > This counter should never be reset.
>
> So this timer should always be on, no matter what happens to the system.

What I mean is that at no point should the clocksource counter be re-
initialized while the system is running and it is in use, otherwise
the 'delta' value will spike and 'ns' will become very large.  You'll
then find the kernels idea of time spontaneously jumps forward when
it shouldn't.

> > A clockevent device is some sort of timer which it used to trigger either
> > a periodic interrupt or a one-shot interrupt to cause CPUs to do some
> > maintainence task (such as reading the clock source, comparing that with
> > the previous reading, and using the delta to update the kernels idea of
> > current time.)
>
> This is used for setting up the next event by using the set_next_event
> callback and set the mode(one shot or periodic) by set_mode callback.
> So, this timer is the heart of tickless kernel functionality(NO_HZ).

Correct.  The mode is changed when required - when switching to periodic
mode, you're expected to program the hardware for that mode and set it
up to produce interrupts at a frequency of HZ.

When you're called to switch to one-shot mode, program it for one-shot
mode, disable it, and wait for set_next_event().  On set_next_event(),
you program the timer to produce an interrupt after the specified
interval and enable it.

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Thu, Apr 28, 2011 at 7:58 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Apr 28, 2011 at 07:24:41PM +0530, Vikram Narayanan wrote:
>> On Thu, Apr 28, 2011 at 7:08 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Apr 28, 2011 at 07:01:53PM +0530, Vikram Narayanan wrote:
>> >> I am still confused about the terms clocksource and clockevents. Can
>> >> someone please explain it in simple terms or lead me to a good
>> >> documentation that elaborates clearly about this?
>> >
>> > A clocksource is a monotonically incrementing counter which measures the
>> > passing of time.
>>
>> So, this is the timer that keeps the wall time always up as long as
>> the system is running. If the system isn't running, a backup RTC
>> should take care of the time. When the system is back, again
>> clocksource will be having the control.
>> Even if the above timer count overflows, that should be taken care of.
>
> What basically happens is:
>
> ? ? ? ?now = cs->read(cs);
> ? ? ? ?delta = (now - cs->cycle_last) & cs->mask;
> ? ? ? ?cs->cycle_last = now;
>
> ? ? ? ?ns = clocksource_cyc2ns(delta, cs...);
>
> ns now represents the amount of time which passed between this read and
> the previous read. ?Note the mask in the calculation of delta ensures
> that overflows are taken care of.

The timekeeping_get_ns() in kernel/time/timekeeping.c takes care of the above.
So my job is to provide a good *continuous* clocksource with correct
mult,shift and mask values.
And also, the mult and shift values can be calculated from the
clocks_calc_mult_shift() function.
Then the arch independent code takes care of everything.

>
>> > This counter should never be reset.
>>
>> So this timer should always be on, no matter what happens to the system.
>
> What I mean is that at no point should the clocksource counter be re-
> initialized while the system is running and it is in use, otherwise
> the 'delta' value will spike and 'ns' will become very large. ?You'll
> then find the kernels idea of time spontaneously jumps forward when
> it shouldn't.
>
>> > A clockevent device is some sort of timer which it used to trigger either
>> > a periodic interrupt or a one-shot interrupt to cause CPUs to do some
>> > maintainence task (such as reading the clock source, comparing that with
>> > the previous reading, and using the delta to update the kernels idea of
>> > current time.)
>>
>> This is used for setting up the next event by using the set_next_event
>> callback and set the mode(one shot or periodic) by set_mode callback.
>> So, this timer is the heart of tickless kernel functionality(NO_HZ).
>
> Correct. ?The mode is changed when required - when switching to periodic
> mode, you're expected to program the hardware for that mode and set it
> up to produce interrupts at a frequency of HZ.
>
The define HZ is important only for one-shot mode. and for a tickless
kernel this value is not of great importance.
And also if I use the same timer for clocksource and clockevent, it
will surely gonna mess up my system's time sooner or latter.
> When you're called to switch to one-shot mode, program it for one-shot
> mode, disable it, and wait for set_next_event(). ?On set_next_event(),
> you program the timer to produce an interrupt after the specified
> interval and enable it.
>
For the clockevent device, If I provide all the data structures,
next_event and set_mode, then this will work perfectly.

Hope I have understood your explanations in the right way and all my
above statements make sense.

Thanks,
Vikram

Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 10:59:01PM +0530, Vikram Narayanan wrote:
> On Thu, Apr 28, 2011 at 7:58 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > What basically happens is:
> >
> > ? ? ? ?now = cs->read(cs);
> > ? ? ? ?delta = (now - cs->cycle_last) & cs->mask;
> > ? ? ? ?cs->cycle_last = now;
> >
> > ? ? ? ?ns = clocksource_cyc2ns(delta, cs...);
> >
> > ns now represents the amount of time which passed between this read and
> > the previous read. ?Note the mask in the calculation of delta ensures
> > that overflows are taken care of.
> 
> The timekeeping_get_ns() in kernel/time/timekeeping.c takes care of the above.
> So my job is to provide a good *continuous* clocksource with correct
> mult,shift and mask values.
> And also, the mult and shift values can be calculated from the
> clocks_calc_mult_shift() function.

For clocksources, please, no, don't use clocks_calc_mult_shift().  There
is clocksource_register_hz() and clocksource_register_khz() which will
sort out the shift and multiplier automatically for you.

> The define HZ is important only for one-shot mode. and for a tickless
> kernel this value is not of great importance.

ITYM periodic mode.

> And also if I use the same timer for clocksource and clockevent, it
> will surely gonna mess up my system's time sooner or latter.

Indeed it will.

> > When you're called to switch to one-shot mode, program it for one-shot
> > mode, disable it, and wait for set_next_event(). ?On set_next_event(),
> > you program the timer to produce an interrupt after the specified
> > interval and enable it.
>
> For the clockevent device, If I provide all the data structures,
> next_event and set_mode, then this will work perfectly.
> 
> Hope I have understood your explanations in the right way and all my
> above statements make sense.

I think so.

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Thu, Apr 28, 2011 at 11:54 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Apr 28, 2011 at 10:59:01PM +0530, Vikram Narayanan wrote:
>> On Thu, Apr 28, 2011 at 7:58 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > What basically happens is:
>> >
>> > ? ? ? ?now = cs->read(cs);
>> > ? ? ? ?delta = (now - cs->cycle_last) & cs->mask;
>> > ? ? ? ?cs->cycle_last = now;
>> >
>> > ? ? ? ?ns = clocksource_cyc2ns(delta, cs...);
>> >
>> > ns now represents the amount of time which passed between this read and
>> > the previous read. ?Note the mask in the calculation of delta ensures
>> > that overflows are taken care of.
>>
>> The timekeeping_get_ns() in kernel/time/timekeeping.c takes care of the above.
>> So my job is to provide a good *continuous* clocksource with correct
>> mult,shift and mask values.
>> And also, the mult and shift values can be calculated from the
>> clocks_calc_mult_shift() function.
>
> For clocksources, please, no, don't use clocks_calc_mult_shift(). ?There
> is clocksource_register_hz() and clocksource_register_khz() which will
> sort out the shift and multiplier automatically for you.
Ok. I will use this.
>
>> The define HZ is important only for one-shot mode. and for a tickless
>> kernel this value is not of great importance.
>
> ITYM periodic mode.
Yes. in periodic mode. I mistyped it.
>
>> And also if I use the same timer for clocksource and clockevent, it
>> will surely gonna mess up my system's time sooner or latter.
>
> Indeed it will.
Can you also give some idea on how the system's RTC is hooked up with
the generic timekeeping code.
Is it hooked up in someway so that the walltime is calculated wrt the
initial value of the RTC?
>
>> > When you're called to switch to one-shot mode, program it for one-shot
>> > mode, disable it, and wait for set_next_event(). ?On set_next_event(),
>> > you program the timer to produce an interrupt after the specified
>> > interval and enable it.
>>
>> For the clockevent device, If I provide all the data structures,
>> next_event and set_mode, then this will work perfectly.
>>
>> Hope I have understood your explanations in the right way and all my
>> above statements make sense.
>
> I think so.
>
Thanks for your detailed explanations.
Will update this thread if I have more doubts on this.

Thanks,
Vikram

Architecture specific implementations for tickless kernel and deferrable timers

[Russell King - ARM Linux]

On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
> Can you also give some idea on how the system's RTC is hooked up with
> the generic timekeeping code.
> Is it hooked up in someway so that the walltime is calculated wrt the
> initial value of the RTC?

I'd like to pass you over to the RTC folk, but I don't think they're
very active anymore.

Suffice it to say that the RTC subsystem will set the system date/time
on initialization from the RTC device if one is provided.  All I can
suggest is to look at drivers/rtc and include/linux/rtc.h for the
details.  The MAINTAINERS file should list who is responsible for RTC
stuff as well as a mailing list for it.

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Fri, Apr 29, 2011 at 8:04 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
>> Can you also give some idea on how the system's RTC is hooked up with
>> the generic timekeeping code.
>> Is it hooked up in someway so that the walltime is calculated wrt the
>> initial value of the RTC?
>
> I'd like to pass you over to the RTC folk, but I don't think they're
> very active anymore.
>
> Suffice it to say that the RTC subsystem will set the system date/time
> on initialization from the RTC device if one is provided. ?All I can
> suggest is to look at drivers/rtc and include/linux/rtc.h for the
> details. ?The MAINTAINERS file should list who is responsible for RTC
> stuff as well as a mailing list for it.
>
Yes. Sure. I already have a driver in place for RTC, under /dev/rtc. I
will try to post my doubts in the RTC mailing lists.
Just noticed a folder clocksource under drivers.
Quite curious about what it is for?
Can you give some hints about it?

Thanks,
Vikram

Architecture specific implementations for tickless kernel and deferrable timers

[Thomas Gleixner]

On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:

> On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
> > Can you also give some idea on how the system's RTC is hooked up with
> > the generic timekeeping code.
> > Is it hooked up in someway so that the walltime is calculated wrt the
> > initial value of the RTC?
> 
> I'd like to pass you over to the RTC folk, but I don't think they're
> very active anymore.
> 
> Suffice it to say that the RTC subsystem will set the system date/time
> on initialization from the RTC device if one is provided.  All I can
> suggest is to look at drivers/rtc and include/linux/rtc.h for the
> details.  The MAINTAINERS file should list who is responsible for RTC
> stuff as well as a mailing list for it.

read_persistant_clock() is used for boottime / resume time readouts of
a direct accessible RTC.

If the RTC sits behind a slow bus which is not accessible in early
boot, then the RTC framework will take care of updating the time once
the RTC becomes available.

John Stultz is the guy who knows all the details.

Thanks,

	tglx

Architecture specific implementations for tickless kernel and deferrable timers

[Thomas Gleixner]

On Fri, 29 Apr 2011, Vikram Narayanan wrote:

> On Fri, Apr 29, 2011 at 8:04 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
> >> Can you also give some idea on how the system's RTC is hooked up with
> >> the generic timekeeping code.
> >> Is it hooked up in someway so that the walltime is calculated wrt the
> >> initial value of the RTC?
> >
> > I'd like to pass you over to the RTC folk, but I don't think they're
> > very active anymore.
> >
> > Suffice it to say that the RTC subsystem will set the system date/time
> > on initialization from the RTC device if one is provided. ?All I can
> > suggest is to look at drivers/rtc and include/linux/rtc.h for the
> > details. ?The MAINTAINERS file should list who is responsible for RTC
> > stuff as well as a mailing list for it.
> >
> Yes. Sure. I already have a driver in place for RTC, under /dev/rtc. I
> will try to post my doubts in the RTC mailing lists.
> Just noticed a folder clocksource under drivers.
> Quite curious about what it is for?
> Can you give some hints about it?

That's for clock sources which are shared accross platforms.

Thanks,

	tglx

Architecture specific implementations for tickless kernel and deferrable timers

[john stultz]

On Fri, 2011-04-29 at 19:05 +0200, Thomas Gleixner wrote:
> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
> 
> > On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
> > > Can you also give some idea on how the system's RTC is hooked up with
> > > the generic timekeeping code.
> > > Is it hooked up in someway so that the walltime is calculated wrt the
> > > initial value of the RTC?
> > 
> > I'd like to pass you over to the RTC folk, but I don't think they're
> > very active anymore.
> > 
> > Suffice it to say that the RTC subsystem will set the system date/time
> > on initialization from the RTC device if one is provided.  All I can
> > suggest is to look at drivers/rtc and include/linux/rtc.h for the
> > details.  The MAINTAINERS file should list who is responsible for RTC
> > stuff as well as a mailing list for it.
> 
> read_persistant_clock() is used for boottime / resume time readouts of
> a direct accessible RTC.

Right. read_persistent_clock has the benefit of being able to be read
with irqs off, which really is useful in reducing error in the
suspend/resume code. This makes it the preferred interface for
timekeeping.


> If the RTC sits behind a slow bus which is not accessible in early
> boot, then the RTC framework will take care of updating the time once
> the RTC becomes available.

Right. I sent out a patch "Add timekeeping_inject_sleeptime" that
corrects the irqs-required RTC paths on suspend and resume, which Thomas
just pulled into -tip for 2.6.40. It should improve things on the
non-read_persistent_clock/irq-required RTC side of things.

With 2.6.39 and earlier, the RTC code basically just calls
settimeofday() fairly late in the resume step, which makes a window for
resume timestamps to show the suspend time, as well as not properly
allowing us to account for the amount of time the system was sleeping
(which mucks up the boot time).

Of course, another issue with the RTC interface is that it
isbottlenecked at second granularity, which also hurts suspend/resume
time accuracy. Where as read_persistent_clock() allows for finer grained
resolution (if possible).

Let me know if you have any more questions I can try to answer.

thanks
-john

Architecture specific implementations for tickless kernel and deferrable timers

[Vikram Narayanan]

On Fri, Apr 29, 2011 at 11:27 PM, john stultz <johnstul@us.ibm.com> wrote:
> On Fri, 2011-04-29 at 19:05 +0200, Thomas Gleixner wrote:
>> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
>>
>> > On Fri, Apr 29, 2011 at 07:56:56PM +0530, Vikram Narayanan wrote:
>> > > Can you also give some idea on how the system's RTC is hooked up with
>> > > the generic timekeeping code.
>> > > Is it hooked up in someway so that the walltime is calculated wrt the
>> > > initial value of the RTC?
>> >
>> > I'd like to pass you over to the RTC folk, but I don't think they're
>> > very active anymore.
>> >
>> > Suffice it to say that the RTC subsystem will set the system date/time
>> > on initialization from the RTC device if one is provided. ?All I can
>> > suggest is to look at drivers/rtc and include/linux/rtc.h for the
>> > details. ?The MAINTAINERS file should list who is responsible for RTC
>> > stuff as well as a mailing list for it.
>>
>> read_persistant_clock() is used for boottime / resume time readouts of
>> a direct accessible RTC.
>
> Right. read_persistent_clock has the benefit of being able to be read
> with irqs off, which really is useful in reducing error in the
> suspend/resume code. This makes it the preferred interface for
> timekeeping.
>
>
>> If the RTC sits behind a slow bus which is not accessible in early
>> boot, then the RTC framework will take care of updating the time once
>> the RTC becomes available.
>
> Right. I sent out a patch "Add timekeeping_inject_sleeptime" that
> corrects the irqs-required RTC paths on suspend and resume, which Thomas
> just pulled into -tip for 2.6.40. It should improve things on the
> non-read_persistent_clock/irq-required RTC side of things.
>
> With 2.6.39 and earlier, the RTC code basically just calls
> settimeofday() fairly late in the resume step, which makes a window for
> resume timestamps to show the suspend time, as well as not properly
> allowing us to account for the amount of time the system was sleeping
> (which mucks up the boot time).
>
> Of course, another issue with the RTC interface is that it
> isbottlenecked at second granularity, which also hurts suspend/resume
> time accuracy. Where as read_persistent_clock() allows for finer grained
> resolution (if possible).
>
> Let me know if you have any more questions I can try to answer.
Thank you all for the explanations. I will update the thread, if I
have more questions. :)

-
Thanks,
Vikram