linux-kernel - Re: [RFC] Introduce greedy hrtimer walk on idle

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: <1317218613.24040.22.camel@twins>
Date:	Wed, 28 Sep 2011 16:03:33 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Venki Pallipadi <venki@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Introduce greedy hrtimer walk on idle

On Wed, 2011-09-28 at 07:01 -0700, Arjan van de Ven wrote:
> 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@...radead.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.

Fair enough.. so far it has not been a problem yet, mostly because we
have to run all timers from softirq due to other wreckage (which makes
the whole thing preemptible etc..). But once we can actually get away
with running timers from hardirq again we'll have to sort something out.

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