[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170714162619.GJ3441@tassilo.jf.intel.com>
Date: Fri, 14 Jul 2017 09:26:19 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Li, Aubrey" <aubrey.li@...ux.intel.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Christoph Lameter <cl@...ux.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, daniel.lezcano@...aro.org
Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
> And as said; Daniel has been working on a better predictor -- now he's
> probably not used it on the network workload you're looking at, so that
> might be something to consider.
Deriving a better idle predictor is a bit orthogonal to fast idle.
It would be a good idea to set the fast idle threshold to be the
same as intel_idle would use on that platform and rerun the benchmarks
Then the Cx pattern should be mostly identical, and fast idle can be
evaluated on its own benefits.
-Andi
Powered by blists - more mailing lists