[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170712121406.ugz7wvzz7lrgohqo@hirez.programming.kicks-ass.net>
Date: Wed, 12 Jul 2017 14:14:06 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Li, Aubrey" <aubrey.li@...ux.intel.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Christoph Lameter <cl@...ux.com>,
Andi Kleen <ak@...ux.intel.com>,
Aubrey Li <aubrey.li@...el.com>, tglx@...utronix.de,
len.brown@...el.com, rjw@...ysocki.net, tim.c.chen@...ux.intel.com,
arjan@...ux.intel.com, paulmck@...ux.vnet.ibm.com,
yang.zhang.wz@...il.com, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
On Wed, Jul 12, 2017 at 12:15:08PM +0800, Li, Aubrey wrote:
> While my proposal is trying to leverage the prediction functionality
> of the existing idle menu governor, which works very well for a long
> time.
Oh, so you've missed the emails where people say its shit? ;-)
Look for the emails of Daniel Lezcano who has been working on better
estimating the IRQ periodicity. Some of that has recently been merged
but it hasn't got any users yet afaik.
But as said before, I'm not convinced the actual idle time is the right
measure for NOHZ, because many interrupts do not in fact re-enable the
tick.
Powered by blists - more mailing lists