public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Patryk Wlazlyn <patryk.wlazlyn@linux.intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com,
	len.brown@intel.com, dave.hansen@linux.intel.com
Subject: Re: [PATCH v2 2/3] x86/smp: Allow forcing the mwait hint for play dead loop
Date: Wed, 30 Oct 2024 13:11:05 -0700	[thread overview]
Message-ID: <b01cc6de-8440-477a-9844-d921da9dceb7@intel.com> (raw)
In-Reply-To: <CAJZ5v0j+Qc+5PtPdsDy5B0iAGWOxYbKdUOkVmL_jPNVO8fNK=g@mail.gmail.com>

On 10/30/24 12:53, Rafael J. Wysocki wrote:
> clearly referred to as a kexec() hack, which cannot be done in
> cpuidle_play_dead() because the cpuidle driver doesn't know how to get
> to md->control.

What if we have an mwait_play_dead() _helper_?  It takes the hint as an
argument and retains all the kexec hacks.  All the cpuidle driver has to
do is call the helper with the hint that the cpuidle driver determines.

  reply	other threads:[~2024-10-30 20:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29 10:15 [PATCH v2 0/3] SRF: Fix offline CPU preventing pc6 entry Patryk Wlazlyn
2024-10-29 10:15 ` [PATCH v2 1/3] x86/smp: Move mwait hint computation out of mwait_play_dead Patryk Wlazlyn
2024-10-29 10:15 ` [PATCH v2 2/3] x86/smp: Allow forcing the mwait hint for play dead loop Patryk Wlazlyn
2024-10-29 18:30   ` Dave Hansen
2024-10-30  9:58     ` Artem Bityutskiy
2024-10-30 19:32       ` Dave Hansen
2024-10-30 19:53         ` Rafael J. Wysocki
2024-10-30 20:11           ` Dave Hansen [this message]
2024-10-30 20:14             ` Rafael J. Wysocki
2024-11-06  8:14         ` Artem Bityutskiy
2024-11-06 14:46           ` Dave Hansen
2024-10-30 13:33     ` Patryk Wlazlyn
2024-10-30 22:55       ` Dave Hansen
2024-10-29 10:15 ` [PATCH v2 3/3] intel_idle: Identify the deepest cstate for SRF Patryk Wlazlyn

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=b01cc6de-8440-477a-9844-d921da9dceb7@intel.com \
    --to=dave.hansen@intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=patryk.wlazlyn@linux.intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox