linux-kernel - Re: hrtimer: about hres

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]

Message-ID: <alpine.LFD.2.00.1005101707410.3401@localhost.localdomain>
Date:	Mon, 10 May 2010 17:12:50 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Iram Shahzad <iram.shahzad@...fujitsu.com>
cc:	linux-kernel@...r.kernel.org
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
--
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/