[sles-beta] intel_idle

[Scott Bahling]

On Wed, 2014-07-23 at 16:44 +0000, Waite, Dick wrote:
> Many Thanks for the update Scott. A couple / few of customers did not
> like the idea of having to amend the boot parm and at the time some
> words were written about using in a later kernel, syscntl.conf which
> customers preferred over amending boot as their system providers
> charged extra...

Starting with SLES 11 SP3 (latest updates) the cpupower command will
allow to dynamically control the idle states via command line at run
time. This is a better option than the kernel parameter. It's
recommended to test with disabling only the highest c-states until the
desired performance/latency is achieved. Disabling too many c-states can
have adverse affects.

> If the parm was not in boot then I think more customers would be
> willing to amend this value, I wonder how many customer get better
> results with the default, do you have any numbers?

I'm not sure what kind of numbers you mean. Better results depends on
workload requirements related to latency and performance/watt. The
results depend on the exact hardware in use as each CPU and platform
comes with it's own power vs performance features and behavioral
profiles. For instance, disabling certain c-states can disable
turbo-boost functionality in modern CPUs which could rob some workloads
of a potential performance boost.

For a majority of workloads out there, the defaults should be just fine.
For those workloads that need extra attention to either performance or
power efficiency, tuning is necessary.

-Scott

> __R
> ________________________________________
> From: Scott Bahling [sbahling at suse.com]
> Sent: 23 July 2014 12:09
> To: Waite, Dick
> Cc: sles-beta at lists.suse.com
> Subject: Re: [sles-beta] intel_idle
> 
> On Wed, 2014-07-23 at 06:55 +0000, Waite, Dick wrote:
> > Grand Day,
> >
> >     When running some SLES11 on X86_64 sites some time ago the "batch"
> > jobs were taking 30-50% more wall clock time. After some time a
> > work-a-round was found to amend the "Intel_Idle" parm. There was some
> > chatter at the time that a "better" fix would be available with a
> > later Linux release. I'm going to visit one of our customers who had
> > this issue in a few weeks time, what news do I have for them?
> 
> It depends on the exact tuning ("work-a-round") used.
> 
> There has been an optimization related to disabling promotion to C1E
> state so using intel_idle.max_cstate=1 might give better results with
> SUSE Linux Enterprise Server 12 and remove the need to disable the
> intel_idle driver completely. It depends on the workload and CPU model
> in use.
> 
> Other than that, the intel_idle driver and it's parameters should work
> the same in 12 as in 11 - meaning if c-states affect your workload,
> tuning of the intel_idle driver might be necessary.
> 
> Best Regards,
> 
> Scott
> 
> --
> Scott Bahling     | Technical Account Manager - Team Lead
> +49 911-74053-121 | Mobile: +49 173-587-6977 | sbahling at suse.com
> SUSE Linux Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nuremberg)
> 
> 
> Software AG  Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany  Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>