Messages in this thread | | | Date | Mon, 10 May 2010 17:12:50 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: hrtimer: about hres_active |
| |
Iram,
On Mon, 10 May 2010, Iram Shahzad wrote:
> I am trying to understand the purpose of "hres_active" of hrtimer > and have the following question in this regard. > > It seems "hres_active" indicates whether high resolution mode is > active or not. But I am not clear about the idea behind it. > > I see that hres_active is initialized to 0 here: > hrtimer_init_hres > > and set to 1 here: > hrtimer_run_pending > -> hrtimer_switch_to_hres > > That means hrtimer becomes "active" at the 1st timer softirq > and remains so forever. Is this understanding correct?
No. The system switches to high resolution mode late in the boot process and it does so only when there is high res capable hardware available.
> My original concern is as follows: > > hrtimer_get_next_event returns KTIME_MAX when hrtimer is "active". > So if the above understanding is correct, then after the 1st timer > softirq it will always return KTIME_MAX. This means cpu_idle will never > take the hrtimer event into account and will always base its decision > on the next event of the timer wheel. Is this intended behaviour?
Yes it is. In the case of high res active the hrtimer which is the next to expire is already armed on that CPU in the clock event device. Therefor we know already when the next hrtimer will fire. No need to lookup further. But we have to check the timer wheel as it might have a timer which is due earlier than the first to expire hrtimer.
Thanks,
tglx
| |