linux-kernel - Re: [PATCH] hrtimers, timers: eliminate some jiffies-backed code

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] [day] [month] [year] [list]

Message-ID: <4F1FCF6A.20108@linaro.org>
Date:	Wed, 25 Jan 2012 13:46:18 +0400
From:	Dmitry Antipov <dmitry.antipov@...aro.org>
To:	john stultz <johnstul@...ibm.com>
CC:	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Amit Kucheria <amit.kucheria@...aro.org>
Subject: Re: [PATCH] hrtimers, timers: eliminate some jiffies-backed code

On 01/25/2012 04:01 AM, john stultz wrote:

> Why do you want to move loops like the above from jiffies based timeouts
> to hrtimers?

I'm trying to see whether there are possible benefits in the sense of power management.
More hrtimers with larger expire deltas -> more opportunities to coalesce hrtimer
interrupts -> less frequency of hrtimer interrupts -> longer idle/suspend/stanby/etc.
periods.

> Is there an actual need for sub-jiffy granularity in these sorts of
> timeouts?

I didn't collect a representative statistics among the large set of different drivers,
but I believe the answer is 'no' for the most of them. The main reason is described above.

> Or is this really just a "getting away from using jiffies" cleanup?

A bit of this too, definitely. Documentation/timers/highres.txt notices 'complete jiffies
removal' as something which may take place sometime; at least, I don't have an ideas why
to use jiffies in a new code.

> Calling get_time() again on each hrtimer_wakeup isn't free.
>
> With this we end up when the irq fires, calling hrtimer_interrupt, which
> reads the time and goes through the timer list running expired timers,
> which then runs the sleeper's timer which then reads the time again!
> Additinoally, this extra overhead is done even no one wants the elapsed
> time.

Thanks, I'll think about reworking of this.

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