All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patryk Wlazlyn <patryk.wlazlyn@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	rafael.j.wysocki@intel.com, len.brown@intel.com,
	artem.bityutskiy@linux.intel.com, dave.hansen@linux.intel.com
Subject: Re: [PATCH v3 2/3] x86/smp native_play_dead: Prefer cpuidle_play_dead() over mwait_play_dead()
Date: Tue, 12 Nov 2024 11:55:56 +0100	[thread overview]
Message-ID: <89ebe611-a9b8-43f5-bb52-e8a299f79188@linux.intel.com> (raw)
In-Reply-To: <394fa854-41a9-4ad1-880b-629108d52b41@intel.com>

> I don't think the bug has anything to do with this patch, really.
> There's no need to rehash it here.
>
> The issue here is that the only way to call mwait today is via
> mwait_play_dead() directly, using its internally-calculated hint.
>
> What you want is for a cpuidle-driver-calculated hint to be used.  So,
> you're using the new hint function via the cpuidle driver.  But you just
> need the cpuidle driver to be called first, not the old
> mwait_play_dead()-calculated hint.  The new code will still do mwait,
> just via a different path and with a different hint.

Ok. I'll just say that we change the order because idle driver may know better.

> The thing this doesn't mention is what the impact on everyone else is.
> I _think_ the ACPI cpuidle driver is the only worry.  Today, if there's
> a system that supports mwait and ACPI cpuidle, it'll use mwait.  After
> this patch, it'll use ACPI cpuidle.
>
> The changelog doesn't mention that behavior change or why that's OK.

True, but I think the mwait_play_dead() is exclusively for Intel. Other target
platforms get an early return. I'll include that in the commit message.

> Also, looking at this:
>
>> -    mwait_play_dead();
>>      if (cpuidle_play_dead())
>> -        hlt_play_dead();
>> +        mwait_play_dead();
>> +    hlt_play_dead();
>
> None of those return on success, right?
>
> Is there any reason this couldn't just be:
>
>     /* The first successful play_dead() will not return: */
>     cpuidle_play_dead();
>     mwait_play_dead();
>     hlt_play_dead();
>
> That has the added bonus of not needing to return anything from
> mwait_play_dead() and the resulting churn from the last patch.

mwait_play_dead may return if mwait_play_dead_with_hint returns and it only does
on non-smp builds. That being said, we do ignore the return value right now,
because in either case we want to enter hlt_play_dead() as a fallback, so I
guess we can make mwait_play_dead return void, but leave
mwait_play_dead_with_hint returning int or add ifdef CONFIG_SMP guards in
intel_idle.

When going with the return types proposed in this patch set, on non-smp builds
intel_idle would call mwait_play_dead_with_hint() which would "return 1"; and
propagate through cpuidle_play_dead().


  reply	other threads:[~2024-11-12 10:56 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 12:29 [PATCH v3 0/3] SRF: Fix offline CPU preventing pc6 entry Patryk Wlazlyn
2024-11-08 12:29 ` [PATCH v3 1/3] x86/smp: Allow calling mwait_play_dead with arbitrary hint Patryk Wlazlyn
2024-11-08 16:03   ` Dave Hansen
2024-11-12 10:54     ` Patryk Wlazlyn
2024-11-08 12:29 ` [PATCH v3 2/3] x86/smp native_play_dead: Prefer cpuidle_play_dead() over mwait_play_dead() Patryk Wlazlyn
2024-11-08 16:14   ` Dave Hansen
2024-11-12 10:55     ` Patryk Wlazlyn [this message]
2024-11-12 11:47   ` Peter Zijlstra
2024-11-12 12:03     ` Rafael J. Wysocki
2024-11-12 12:18       ` Peter Zijlstra
2024-11-12 12:30         ` Rafael J. Wysocki
2024-11-12 12:38           ` Rafael J. Wysocki
2024-11-12 13:49           ` Peter Zijlstra
2024-11-12 14:56             ` Rafael J. Wysocki
2024-11-12 15:08               ` Peter Zijlstra
2024-11-12 16:24                 ` Rafael J. Wysocki
2024-11-12 12:44         ` Artem Bityutskiy
2024-11-12 14:01           ` Peter Zijlstra
2024-11-14 12:03             ` Peter Zijlstra
2024-11-15  1:21               ` Thomas Gleixner
2024-11-15 10:07                 ` Peter Zijlstra
2024-11-15 15:37                   ` Thomas Gleixner
2024-11-12 13:23     ` Rafael J. Wysocki
2024-11-12 14:56       ` Peter Zijlstra
2024-11-12 15:00         ` Rafael J. Wysocki
2024-11-13 11:41         ` Gautham R. Shenoy
2024-11-13 16:14           ` Dave Hansen
2024-11-14  5:06             ` Gautham R. Shenoy
2024-11-13 16:22           ` Peter Zijlstra
2024-11-13 16:27             ` Wysocki, Rafael J
2024-11-14 11:58               ` Rafael J. Wysocki
2024-11-14 12:17                 ` Peter Zijlstra
2024-11-14 17:36             ` Gautham R. Shenoy
2024-11-14 17:58               ` Rafael J. Wysocki
2024-11-14 11:58           ` Peter Zijlstra
2024-11-14 17:24             ` Gautham R. Shenoy
2024-11-15 10:11               ` Peter Zijlstra
2024-11-25  5:45                 ` Gautham R. Shenoy
2024-11-08 12:29 ` [PATCH v3 3/3] intel_idle: Provide enter_dead() handler for SRF Patryk Wlazlyn
2024-11-08 16:21   ` Dave Hansen
2024-11-12 10:57     ` Patryk Wlazlyn
2024-11-12 11:28       ` Rafael J. Wysocki
2024-11-12 16:07         ` Dave Hansen
2024-11-12 19:17         ` Thomas Gleixner
2024-11-12 19:43           ` Rafael J. Wysocki
2024-11-08 22:12   ` kernel test robot
2024-11-08 16:22 ` [PATCH v3 0/3] SRF: Fix offline CPU preventing pc6 entry Dave Hansen
2024-11-12 11:45 ` Peter Zijlstra
2024-11-12 15:43   ` Patryk Wlazlyn
2024-11-13  1:19     ` Thomas Gleixner
2024-11-14 17:13       ` 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=89ebe611-a9b8-43f5-bb52-e8a299f79188@linux.intel.com \
    --to=patryk.wlazlyn@linux.intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=dave.hansen@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=rafael.j.wysocki@intel.com \
    --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.