From: Arjan van de Ven <arjan@linux.intel.com>
To: Venkatesh Pallipadi <venki@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Suresh Siddha <suresh.b.siddha@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Introduce greedy hrtimer walk on idle
Date: Fri, 23 Sep 2011 12:29:35 -0700 [thread overview]
Message-ID: <4E7CDE1F.90004@linux.intel.com> (raw)
In-Reply-To: <1316804080-6396-1-git-send-email-venki@google.com>
On 9/23/2011 11:54 AM, Venkatesh Pallipadi wrote:
> Current hrtimer range timers reduces the number of timer interrupts by
> grouping together softexpired timers until the next unexpired timer.
> It does not look at softexpired timers that may be after the unexpired
> timer in the rbtree.
>
> Specifically, as the comment in hrtimer.c says
> * The immediate goal for using the softexpires is
> * minimizing wakeups, not running timers at the
> * earliest interrupt after their soft expiration.
> * This allows us to avoid using a Priority Search
> * Tree, which can answer a stabbing querry for
> * overlapping intervals and instead use the simple
> * BST we already have.
> * We don't add extra wakeups by delaying timers that
> * are right-of a not yet expired timer, because that
> * timer will have to trigger a wakeup anyway.
>
Since you found that it now makes a difference, I'm all for it..
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
(at original introduction it was in the noise, but usage patterns
clearly changed a lot and ranges are much more prevalent now)
I would not do the sysctl/configurability thing though.... that's not
worth it.
next prev parent reply other threads:[~2011-09-23 19:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-23 18:54 [RFC] Introduce greedy hrtimer walk on idle Venkatesh Pallipadi
2011-09-23 19:29 ` Arjan van de Ven [this message]
2011-09-23 23:50 ` Venki Pallipadi
2011-09-24 0:29 ` Valdis.Kletnieks
2011-09-23 19:55 ` Peter Zijlstra
2011-09-23 23:41 ` Venki Pallipadi
2011-09-28 13:25 ` Peter Zijlstra
2011-09-23 20:03 ` Peter Zijlstra
2011-09-23 23:47 ` Venki Pallipadi
2011-09-28 13:23 ` Peter Zijlstra
2011-09-28 14:01 ` Arjan van de Ven
2011-09-28 14:03 ` Peter Zijlstra
2011-09-23 22:59 ` Andi Kleen
2011-10-26 0:46 ` alex shi
2011-10-26 17:13 ` Venki Pallipadi
2011-10-27 0:59 ` alex shi
2011-11-01 2:11 ` alex shi
2011-11-01 23:55 ` Venki Pallipadi
2011-11-02 1:22 ` alex shi
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=4E7CDE1F.90004@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venki@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.