On Fri, Mar 22, 2013 at 11:37:55AM -0700, Kevin Hilman wrote:
> "Paul E. McKenney" <paul...@linux.vnet.ibm.com> writes:
>
> > On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
> >> On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
> >> > o Use the "idle=poll" boot parameter. However, please note
> >> > that use of this parameter can cause your CPU to overheat,
> >> > which may cause thermal throttling to degrade your
> >> > latencies --and that this degradation can be even worse
> >> > than that of dyntick-idle.
> >>
> >> it also disables (effectively) Turbo Mode on Intel cpus... which can
> >> cost you a serious percentage of performance
> >
> > Thank you, added! Please see below for the updated list.
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > o Dyntick-idle slows transitions to and from idle slightly.
> > In practice, this has not been a problem except for the most
> > aggressive real-time workloads, which have the option of disabling
> > dyntick-idle mode, an option that most of them take. However,
> > some workloads will no doubt want to use adaptive ticks to
> > eliminate scheduling-clock-tick latencies. Here are some
> > options for these workloads:
> >
> > a. Use PMQOS from userspace to inform the kernel of your
> > latency requirements (preferred).
>
> This is not only the preferred approach, but the *only* approach
> available on non-x86 systems. Perhaps the others should be marked as
> x86-only?
Good point, added that.
Thanx, Paul
> Kevin
>
> > b. Use the "idle=mwait" boot parameter.
> >
> > c. Use the "intel_idle.max_cstate=" to limit the maximum
> > depth C-state depth.
> >
> > d. Use the "idle=poll" boot parameter. However, please note
> > that use of this parameter can cause your CPU to overheat,
> > which may cause thermal throttling to degrade your
> > latencies -- and that this degradation can be even worse
> > than that of dyntick-idle. Furthermore, this parameter
> > effectively disables Turbo Mode on Intel CPUs, which
> > can significantly reduce maximum performance.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
