public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Venki Pallipadi <venki@google.com>,
	Thomas Gleixner <tglx@linutronix.de>, 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: Wed, 28 Sep 2011 07:01:06 -0700	[thread overview]
Message-ID: <4E8328A2.3070806@linux.intel.com> (raw)
In-Reply-To: <1317216203.24040.18.camel@twins>

On 9/28/2011 6:23 AM, Peter Zijlstra wrote:
> On Fri, 2011-09-23 at 16:47 -0700, Venki Pallipadi wrote:
>> On Fri, Sep 23, 2011 at 1:03 PM, Peter Zijlstra<peterz@infradead.org>  wrote:
>>> On Fri, 2011-09-23 at 11:54 -0700, Venkatesh Pallipadi wrote:
>>>> Comments?
>>> Looks to be a possible IRQ latency issue as well, that can be a lot of
>>> timers to run..
>>>
>> We could add some rate limit on how many timers we service this way
>> and/or interrupt/disable-enable in the inner loop.
>> But, this would be a problem with current hrtimer as well. When
>> sched_tick timer is not around, we may end up servicing lot of timers
>> depending on number of them and slack. No?
> Right, still something to consider. We might just have to push down on
> slack for -rt or so when it becomes a problem.

that might not be the right answer ;-)
Slack gives you freedom to schedule these guys; without slack you can 
still get bursts of timers, but with no freedom to punt some for RT 
behavior.
with slack, you can run the mandatory ones first, and then the optionals 
until you hit some RT limit.. the optionals you do run are not going
to bunch up to you at the time they become mandatory.



  reply	other threads:[~2011-09-28 14:01 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
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 [this message]
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=4E8328A2.3070806@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox