Re: [RFC] Introduce greedy hrtimer walk on idle

From: Arjan van de Ven
Date: Wed Sep 28 2011 - 10:01:10 EST


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@xxxxxxxxxxxxx> 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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/