From: Ashwin Chaugule <ashwinc@codeaurora.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: [RFC] [PATCH 1/1] hrtimers: Cache next hrtimer
Date: Fri, 28 Aug 2009 01:56:58 -0400 [thread overview]
Message-ID: <4A9771AA.2090004@codeaurora.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0908280111260.2888@localhost.localdomain>
Thomas Gleixner wrote:
> Hmm. That's related to NOHZ I guess. Ok, that's a serious issue and we
> need to look at that.
>
Yes. I'm running with NOHZ.
>> So, you suggest checking the ktime of the hrtimer thats about to expire and
>> compare it with expires_next ?
>>
>
> What's wrong with that ?
>
Nothing :)
Just didn't know the following could have the same effect. (base->offset is confusing)
+ expires = ktime_sub(hrtimer_get_expires(timer), base->offset);
+ if (base->cpu_base->expires_next.tv64 == expires.tv64)
> Can you reevaluate against my patch please ?
>
>
The avg. startup time with your patch came to: 26.4 sec (10 runs) as against 25.8 sec (my patch).
To calculate the hit ratio, I made some changes to your code as shown below.
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 49da79a..91d099c 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -906,19 +906,30 @@ static void __remove_hrtimer(struct hrtimer *timer,
struct hrtimer_clock_base *base,
unsigned long newstate, int reprogram)
{
- if (timer->state & HRTIMER_STATE_ENQUEUED) {
- /*
- * Remove the timer from the rbtree and replace the
- * first entry pointer if necessary.
- */
- if (base->first == &timer->node) {
- base->first = rb_next(&timer->node);
- /* Reprogram the clock event device. if enabled */
- if (reprogram && hrtimer_hres_active())
- hrtimer_force_reprogram(base->cpu_base);
- }
- rb_erase(&timer->node, &base->active);
- }
+ ktime_t expires;
+
+ if (!(timer->state & HRTIMER_STATE_ENQUEUED))
+ goto out;
+
+ /*
+ * Remove the timer from the rbtree and replace the first
+ * entry pointer if necessary.
+ */
+ rb_erase(&timer->node, &base->active);
+
+ if (base->first != &timer->node)
+ goto out;
+
+ base->first = rb_next(&timer->node);
+ /* Reprogram the clock event device. if enabled */
+ if (!reprogram || !hrtimer_hres_active())
+ goto out;
else
timer->total_calls++
+
+ expires = ktime_sub(hrtimer_get_expires(timer), base->offset);
+ if (base->cpu_base->expires_next.tv64 == expires.tv64)
{
timer->cache_hits++
hrtimer_force_reprogram(base->cpu_base);
}
+
+out:
timer->state = newstate;
}
So basically, total_count is the number of times the reprogram would have been forced, cache_hit is number of times it is reduced to.
In my patch I had these counters as follows:
@@ -858,10 +858,18 @@ static void __remove_hrtimer(struct hrtimer *timer,
*/
if (base->first == &timer->node) {
base->first = rb_next(&timer->node);
+#ifdef CONFIG_TIMER_STATS
+ if (reprogram && hrtimer_hres_active())
+ timer->total_calls++;
+#endif
if (next_hrtimer == timer) {
/* Reprogram the clock event device. if enabled */
- if (reprogram && hrtimer_hres_active())
+ if (reprogram && hrtimer_hres_active()) {
hrtimer_force_reprogram(base->cpu_base);
+#ifdef CONFIG_TIMER_STATS
+ timer->cache_hits++;
+#endif
+ }
Both counters are init'd to 0 in hrtimer_init_hres(timer).
Your patch looks perfect but, total_calls is always equal to cache_hits ?! IOW, the timer we're removing is always the next one to expire, hence we see no benefit.
Cheers,
Ashwin
next prev parent reply other threads:[~2009-08-28 5:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 21:51 Ashwin Chaugule
2009-08-27 21:56 ` Ashwin Chaugule
2009-08-27 22:51 ` Thomas Gleixner
2009-08-27 23:09 ` Ashwin Chaugule
2009-08-27 23:16 ` Thomas Gleixner
2009-08-28 5:56 ` Ashwin Chaugule [this message]
2009-08-28 11:17 ` Thomas Gleixner
2009-08-28 16:34 ` Ashwin Chaugule
2009-08-28 18:19 ` Thomas Gleixner
2009-08-28 20:27 ` Ashwin Chaugule
2009-08-30 6:06 ` Ashwin Chaugule
2009-08-30 8:36 ` Thomas Gleixner
2009-08-31 4:17 ` Ashwin Chaugule
2009-08-31 7:08 ` Thomas Gleixner
2009-09-01 3:13 ` Ashwin Chaugule
2009-09-03 17:48 ` Ashwin Chaugule
2009-09-15 9:09 ` [tip:timers/core] hrtimer: Eliminate needless reprogramming of clock events device tip-bot for Ashwin Chaugule
2009-09-15 15:19 ` tip-bot for Ashwin Chaugule
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A9771AA.2090004@codeaurora.org \
--to=ashwinc@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome