[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN6PR1201MB01312A2AB93708B9115D4865F8F80@BN6PR1201MB0131.namprd12.prod.outlook.com>
Date: Mon, 22 May 2017 20:20:56 +0000
From: "Ghannam, Yazen" <Yazen.Ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
CC: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"len.brown@...el.com" <len.brown@...el.com>,
"pavel@....cz" <pavel@....cz>
Subject: RE: [PATCH] x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD
systems
> -----Original Message-----
> From: Borislav Petkov [mailto:bp@...en8.de]
> Sent: Monday, May 22, 2017 12:22 PM
>
...
> What about x86_idle?
>
> That whole select_idle_routine() jumping through hoops. That's still doing
> default_idle() on Zen, AFAICT.
>
> Or am I missing something?
>
> Because that still asks prefer_mwait_c1_over_halt() and that needs a family
> check or whatever...
>
I think we leave HALT as the default idle mechanism and allow BIOS to select
other mechanisms through ACPI.
On AMD, HALT allows the hardware to automatically manage its Cstates. This
is useful if the OS doesn't define multiple states like when we use
default_idle_call().
On the other hand, MWAIT on AMD limits the hardware to using only certain,
shallower Cstates. This is okay if we define individual states and use MWAIT
for some of them. But it would consume more power if used always.
Thanks,
Yazen
Powered by blists - more mailing lists