[sles-beta] intel_idle

[Waite, Dick]

Grand New Day Scott,

Very good news, "cpupower" sounds a lot better the boot parm. Could you give me a URL for the SLE12 Docu for this please. We will not change the SLE11 running, leave sleeping dogs lie.

When the new Intel driver bashfully came on the scene, we only run major check with a new version, SLE10, SLE11 and now SLE12, we don't expect a major driver change, with little Docu or readme's on a SP, but now we know better.

The customers found their batch night work running 30% - 50% longer, the night shift was too short... We did work with SUSE on this and got the boot fix. Now with SLE12 it sounds like using the "cpupower" command the customers or in most cases the service provider, in one case that is IBM, can "tune" for best use. When running a "normal" Adabas load during the day with or without the "fix" the performance did not seem any different, it was only running Utility work during the night shift the issues were seen. 

http://www.novell.com/support/kb/doc.php?id=7011982
The URL from Novell gives an outline of the issues and the cpupower command. I'm sure there are some grand words of wisdom on how to best use this. So with this set "correctly" to run Utility at night, would you expect the daily database performance to improve as at the moment it's switched off with the boot fix?

Again many thanks for the update. One of the customers is not from Neuerburg, maybe you would like to pop over when they have SLE12 running and see your work in a customers environment. I know from my own development work, it's grand to see it running in a "real world" environment.

__R
________________________________________
From: Scott Bahling [sbahling at suse.com]
Sent: 24 July 2014 14:01
To: Waite, Dick
Cc: sles-beta at lists.suse.com
Subject: Re: [sles-beta] intel_idle

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
>