Enabling tickless kernel feature in ARM
Hi, I want to enable the dynamic tick aka tickless kernel feature for the BSP which I am developing. What are all the architecture dependent changes that needs to be done for implementing it. There was one struct by the name dyn_tick_timer, which is located under linux/include/asm-arm/mach/time.h file. (which is removed from v 2.6.27) Now my question is that, are all the dyn_tick_timer functionalities are moved to a generic interface somewhere? Are the clock source and clockevent device timers enough to take care of the tickless feature? - Vikram
On Tue, Apr 26, 2011 at 9:55 PM, Vikram Narayanan <vikram186@gmail.com> wrote:
Hi,
I want to enable the dynamic tick aka tickless kernel feature for the BSP which I am developing. What are all the architecture dependent changes that needs to be done for implementing it. There was one struct by the name dyn_tick_timer, which is located under linux/include/asm-arm/mach/time.h file. (which is removed from v 2.6.27) Now my question is that, are all the dyn_tick_timer functionalities are moved to a generic interface somewhere? CONFIG_NO_HZ is used instead.
Are the clock source and clockevent device timers enough to take care of the tickless feature? There's no relationship between NOHZ and clocksource/clockevent.
- Vikram
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Dear Haojian, On Tue, Apr 26, 2011 at 10:04 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
On Tue, Apr 26, 2011 at 9:55 PM, Vikram Narayanan <vikram186@gmail.com> wrote:
Hi,
I want to enable the dynamic tick aka tickless kernel feature for the BSP which I am developing. What are all the architecture dependent changes that needs to be done for implementing it. There was one struct by the name dyn_tick_timer, which is located under linux/include/asm-arm/mach/time.h file. (which is removed from v 2.6.27) Now my question is that, are all the dyn_tick_timer functionalities are moved to a generic interface somewhere? CONFIG_NO_HZ is used instead.
I am aware of the CONFIG_NO_HZ option. I am asking about the implementation of it. To put in a more clear way. There was a structure in the kernel source linux/include/asm-arm/mach/time.h before 2.6.27 struct dyn_tick_timer { spinlock_t lock; unsigned int state; /* Current state */ int (*enable)(void); /* Enables dynamic tick */ int (*disable)(void); /* Disables dynamic tick */ void (*reprogram)(unsigned long); /* Reprograms the timer */ int (*handler)(int, void *); }; To enable dynamic tick timer, one should implement functions for enable, disable and reprogram. But this structure is no more used in the new kernel source. In 2007 linux symposium, 3 authors talked about implementing the tickless feature using HPET timers. Now my question where does the implementation lies in the ARM architecture. Vikram
Are the clock source and clockevent device timers enough to take care of the tickless feature? There's no relationship between NOHZ and clocksource/clockevent.
- Vikram
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Apr 27, 2011 at 11:04 AM, Vikram Narayanan <vikram186@gmail.com> wrote:
Dear Haojian,
On Tue, Apr 26, 2011 at 10:04 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
On Tue, Apr 26, 2011 at 9:55 PM, Vikram Narayanan <vikram186@gmail.com> wrote:
Hi,
I want to enable the dynamic tick aka tickless kernel feature for the BSP which I am developing. What are all the architecture dependent changes that needs to be done for implementing it. There was one struct by the name dyn_tick_timer, which is located under linux/include/asm-arm/mach/time.h file. (which is removed from v 2.6.27) Now my question is that, are all the dyn_tick_timer functionalities are moved to a generic interface somewhere? CONFIG_NO_HZ is used instead.
I am aware of the CONFIG_NO_HZ option. I am asking about the implementation of it. To put in a more clear way. There was a structure in the kernel source linux/include/asm-arm/mach/time.h before 2.6.27
struct dyn_tick_timer { spinlock_t lock; unsigned int state; /* Current state */ int (*enable)(void); /* Enables dynamic tick */ int (*disable)(void); /* Disables dynamic tick */ void (*reprogram)(unsigned long); /* Reprograms the timer */ int (*handler)(int, void *); };
To enable dynamic tick timer, one should implement functions for enable, disable and reprogram. But this structure is no more used in the new kernel source. In 2007 linux symposium, 3 authors talked about implementing the tickless feature using HPET timers. Now my question where does the implementation lies in the ARM architecture.
irq_exit(). While irq handler is finished, timer interrupt should also occur. And jiffies may not sync to latest ticks. The process flow is in below. asm_do_IRQ() --> irq_exit() --> tick_nohz_stop_sched_tick() --> tick_do_update_jiffies64() In tick_do_update_jiffies64(), jiffies will be updated whatever the idle time is 1 jiffies or more.
Are the clock source and clockevent device timers enough to take care of the tickless feature? There's no relationship between NOHZ and clocksource/clockevent.
- Vikram
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Dear Vikram... On Tue, Apr 26, 2011 at 20:55, Vikram Narayanan <vikram186@gmail.com> wrote:
Hi,
I want to enable the dynamic tick aka tickless kernel feature for the BSP which I am developing. What are all the architecture dependent changes that needs to be done for implementing it.
To the best I know: essentially, to achieve tickless ( also know as "no hz"), you need to reprogram your timer chip, so it just "shoot" whenever needed, not periodically. And sometimes, you need to round them up, i.e there are timers which expires in the next 10 ms, 11 ms and 15 ms...so effectively, better to make them expire at 15 ms if possible. so, you need a way to detect the timer expiration (possibly by walking through active timer list) and decide when the timer chip needs to shoot interrupt. The rest of the change...of course...still needed further thinking.... NB: AFAIK In x86, HPET is a prerequisite to achieve tickless... maybe because reprogramming HPET is somewhat way faster than regular PIT -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Dear, On Tue, Apr 26, 2011 at 10:05 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Dear Vikram...
On Tue, Apr 26, 2011 at 20:55, Vikram Narayanan <vikram186@gmail.com> wrote:
Hi,
I want to enable the dynamic tick aka tickless kernel feature for the BSP which I am developing. What are all the architecture dependent changes that needs to be done for implementing it.
To the best I know:
essentially, to achieve tickless ( also know as "no hz"), you need to reprogram your timer chip, so it just "shoot" whenever needed, not periodically. And sometimes, you need to round them up, i.e there are timers which expires in the next 10 ms, 11 ms and 15 ms...so effectively, better to make them expire at 15 ms if possible.
so, you need a way to detect the timer expiration (possibly by walking through active timer list) and decide when the timer chip needs to shoot interrupt. The rest of the change...of course...still needed further thinking....
NB: AFAIK In x86, HPET is a prerequisite to achieve tickless... maybe because reprogramming HPET is somewhat way faster than regular PIT I have read about the dynamic tick feature in lwn.net. When I see the source, it seems to have implemented only with the HPET timers. and also, these dynamic ticks are achieved with hrtimers nowadays. http://lxr.linux.no/#linux+v2.6.38/Documentation/timers/highres.txt#L204 Also I believe most of the implementation is moved to the arch independent part with the help of clocksource and clockevents. Do I need to enable hrtimers for enabling the dynamic tick feature.?
- Thanks Vikram
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi Vikram... On Wed, Apr 27, 2011 at 10:09, Vikram Narayanan <vikram186@gmail.com> wrote:
Do I need to enable hrtimers for enabling the dynamic tick feature.?
maybe... but I am not sure about that... what are the timer provided in your machine, anyway? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Wed, Apr 27, 2011 at 9:59 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi Vikram...
On Wed, Apr 27, 2011 at 10:09, Vikram Narayanan <vikram186@gmail.com> wrote:
Do I need to enable hrtimers for enabling the dynamic tick feature.?
maybe... but I am not sure about that... what are the timer provided in your machine, anyway? Four 16-bit general purpose timers(which can also be used as 32 bit counters), and an RTC (24-bit) The max clock freq is 48 Mhz, which may be downscaled to any value which will be fed as an input to these timers. I guess hrtimers is impossible in these frequencies. What's your opinion on this?
Thanks, Vikram
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Hi Vikram... On Wed, Apr 27, 2011 at 20:49, Vikram Narayanan <vikram186@gmail.com> wrote:
Four 16-bit general purpose timers(which can also be used as 32 bit counters), and an RTC (24-bit) The max clock freq is 48 Mhz, which may be downscaled to any value which will be fed as an input to these timers. I guess hrtimers is impossible in these frequencies. What's your opinion on this?
hard to say, but I guess that "16 bit timer" is something that can be explored first. what you need to pay attention is actually the duration the timer needs to be reprogrammed. The longer it takes, the worse it is...thus you need to avoid it. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Wed, Apr 27, 2011 at 9:07 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi Vikram...
On Wed, Apr 27, 2011 at 20:49, Vikram Narayanan <vikram186@gmail.com> wrote:
Four 16-bit general purpose timers(which can also be used as 32 bit counters), and an RTC (24-bit) The max clock freq is 48 Mhz, which may be downscaled to any value which will be fed as an input to these timers. I guess hrtimers is impossible in these frequencies. What's your opinion on this?
hard to say, but I guess that "16 bit timer" is something that can be explored first. Yes. I am planning to go with it.
what you need to pay attention is actually the duration the timer needs to be reprogrammed. The longer it takes, the worse it is...thus you need to avoid it. I am planning to have a tick of 10ms. i.e the HZ value as 100. Will that be good enough?
- Thanks Vikram
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On 28/04/2011, Vikram Narayanan <vikram186@gmail.com> wrote:
I am planning to have a tick of 10ms. i.e the HZ value as 100. Will that be good enough?
Sorry, you misunderstood me. What I meant was "how long it takes to reprogram the timer, so it ready to deliver another interupt". This is based on my rough info that some timers are quick to be reprogrammed, some are slow...the rest are damn slow. And since we deal with uncertainty (timers could be needed at any point), the fastest one is the best bet. Hopefully I explain it clearly now... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Thu, Apr 28, 2011 at 8:38 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
On 28/04/2011, Vikram Narayanan <vikram186@gmail.com> wrote:
I am planning to have a tick of 10ms. i.e the HZ value as 100. Will that be good enough?
Sorry, you misunderstood me. What I meant was "how long it takes to reprogram the timer, so it ready to deliver another interupt". This is based on my rough info that some timers are quick to be reprogrammed, some are slow...the rest are damn slow. And since we deal with uncertainty (timers could be needed at any point), the fastest one is the best bet.
Hopefully I explain it clearly now... Yeah. Actually I didn't measure the timer reprogramming latency yet. But I think it will be quite good. My assumption may go wrong. Are there any other considerations to take care while implementing the clocksource/clockevents?
Thanks, Vikram
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
participants (3)
-
Haojian Zhuang -
Mulyadi Santosa -
Vikram Narayanan