All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"len.brown@intel.com" <len.brown@intel.com>,
	"pavel@ucw.cz" <pavel@ucw.cz>
Subject: RE: [PATCH] x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems
Date: Mon, 22 May 2017 20:20:56 +0000	[thread overview]
Message-ID: <BN6PR1201MB01312A2AB93708B9115D4865F8F80@BN6PR1201MB0131.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20170522162143.GA19781@nazgul.tnic>

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.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

  reply	other threads:[~2017-05-22 20:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17 14:20 [PATCH] x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD systems Yazen Ghannam
2017-05-17 14:20 ` Yazen Ghannam
2017-05-22 16:21 ` Borislav Petkov
2017-05-22 20:20   ` Ghannam, Yazen [this message]
2017-05-23  7:59     ` Borislav Petkov
2017-05-23 12:50       ` Ghannam, Yazen
2017-05-23 13:06         ` Borislav Petkov
2017-05-23 12:24 ` Pavel Machek
2017-05-24 18:16   ` Ghannam, Yazen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN6PR1201MB01312A2AB93708B9115D4865F8F80@BN6PR1201MB0131.namprd12.prod.outlook.com \
    --to=yazen.ghannam@amd.com \
    --cc=bp@alien8.de \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.