Re: [PATCH] nohz1: Documentation

From: Kevin Hilman
Date: Fri Mar 22 2013 - 14:38:05 EST


"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> 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?

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/