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]

Date:	Tue, 11 May 2010 10:39:12 +0900
From:	"Iram Shahzad" <iram.shahzad@...fujitsu.com>
To:	"Thomas Gleixner" <tglx@...utronix.de>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: hrtimer: about hres_active

Thomas,

Many thanks for the reply. I understood why hrtimer list
is not checked in hrtimer_get_next_event in the case of
high res active.

Please let me ask more about the following.

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

So far as I checked, hres_active is set to 1 in hrtimer_switch_to_hres.
hrtimer_switch_to_hres is only called from hrtimer_run_pending.
And hrtimer_run_pending is called from timer wheel softirq.
That is why I concluded that hres_active is set at 1st timer softirq.
Do you just mean that it is not the 1st softirq, or do you
mean that in some other place in the late boot process
there is another code which sets hres_active?

And is it correct that hres_active remains 1 forever once set to it?

Best regards
Iram

----- Original Message ----- 
From: "Thomas Gleixner" <tglx@...utronix.de>
To: "Iram Shahzad" <iram.shahzad@...fujitsu.com>
Cc: <linux-kernel@...r.kernel.org>
Sent: Tuesday, May 11, 2010 12:12 AM
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/