linux-kernel - Re: [RFC] [PATCH 1/1] hrtimers: Cache next hrtimer

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: <4A9B4ECB.7070506@codeaurora.org>
Date:	Mon, 31 Aug 2009 00:17:15 -0400
From:	Ashwin Chaugule <ashwinc@...eaurora.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: [RFC] [PATCH 1/1] hrtimers: Cache next hrtimer

Thomas Gleixner wrote:

>   
> That's not hard to fix by allowing the reprogramming to skip when the
> new expiry time is the same as the old one.
>
> I think that allowing the reprogram to skip is catching more cases
> than the cached pointer. If the cached pointer is the one which gets
> removed we might still reprogram with the same expiry value.
>   
Um. Wouldn't the cached pointer point to the first (oldest) hrtimer in the 
series of timers with the same expires value ? Then it would be the last
hrtimer to be removed. I'm walking through the rbtree now to confirm this.

> Can you please try the delta patch on top of the last one I sent ?
>   
This looks very good ! 
Our results are almost similar now. However, I think that with this new
patch we're still arming the timer needlessly at least once. This is the
case when we're trying to remove the first (oldest) hrtimer with 
timer->expires = cpu->expires_next, but we forgo the reprogramming, when we 
really shouldn't. At this point, with the current scheme of things, we 
will needlessly wakeup and simply correct the expires_next value by
traversing up the rbtree, to the parent node.

If we knew in advance that this to-be-removed timer, was the oldest hrtimer
of the series, then we could force reprogram, such that we wake up only when the 
parent node timer is really going to expire. This may make a noticeable difference
in power for some devices. 

Another question is, what happens when base->first of REALTIME and MONOTONIC both 
have the same expires ?

Cheers,
Ashwin

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