linux-kernel - 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: <9D38EE7159934A5C85505E9517638040@rainbow>
Date:	Mon, 10 May 2010 19:27:06 +0900
From:	"Iram Shahzad" <iram.shahzad@...fujitsu.com>
To:	<linux-kernel@...r.kernel.org>
Subject: hrtimer: about hres_active

Hi

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?

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?

I would highly appreciate any information about this.
Please CC me because I am not a member of this ML.

Best regards
Iram

--
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/