From: Thomas Gleixner <tglx@linutronix.de>
To: Artem Bityutskiy <dedekind1@gmail.com>,
x86@kernel.org, "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux PM Mailing List <linux-pm@vger.kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH v3 1/2] x86/mwait: Add support for idle via umwait
Date: Fri, 30 Jun 2023 00:04:03 +0200 [thread overview]
Message-ID: <87352a0vu4.ffs@tglx> (raw)
In-Reply-To: <20230610183518.4061159-2-dedekind1@gmail.com>
On Sat, Jun 10 2023 at 21:35, Artem Bityutskiy wrote:
> On Intel platforms, C-states are requested using the 'monitor/mwait'
> instructions pair, as implemented in 'mwait_idle_with_hints()'. This
> mechanism allows for entering C1 and deeper C-states.
>
> Sapphire Rapids Xeon supports new idle states - C0.1 and C0.2 (later C0.x).
> These idle states have lower latency comparing to C1, and can be requested
> with either 'tpause' and 'umwait' instructions.
s/and/or/
>
> Linux already uses the 'tpause' instruction in delay functions like
> 'udelay()'. This patch adds 'umwait' and 'umonitor' instructions
> support.
# git grep 'This patch' Documentation/process/
Please fix it all over the place.
> +#ifdef CONFIG_X86_64
> +/*
> + * Monitor a memory address at 'rcx' using the 'umonitor' instruction.
> + */
> +static inline void __umonitor(const void *rcx)
> +{
> + /* "umonitor %rcx" */
> +#ifdef CONFIG_AS_TPAUSE
Are you sure that the instruction check for TPAUSE is sufficient to also
include UMONITOR on all toolchains which support TPAUSE?
Also:
if (IS_ENABLED(CONFIG_AS_TPAUSE) {
> + asm volatile("umonitor %%rcx\n"
> + :
> + : "c"(rcx));
} else {
> +#else
> + asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf1\t\n"
> + :
> + : "c"(rcx));
}
please.
> +/*
> + * Same as '__tpause()', but uses the 'umwait' instruction. It is very
> + * similar to 'tpause', but also breaks out if the data at the address
> + * monitored with 'umonitor' is modified.
> + */
> +static inline void __umwait(u32 ecx, u32 edx, u32 eax)
> +{
> + /* "umwait %ecx, %edx, %eax;" */
> +#ifdef CONFIG_AS_TPAUSE
> + asm volatile("umwait %%ecx\n"
> + :
> + : "c"(ecx), "d"(edx), "a"(eax));
> +#else
> + asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf1\t\n"
> + :
> + : "c"(ecx), "d"(edx), "a"(eax));
> +#endif
Ditto.
> +/*
> + * Enter C0.1 or C0.2 state and stay there until an event happens (an interrupt
> + * or the 'need_resched()'), the explicit deadline is reached, or the implicit
> + * global limit is reached.
> + *
> + * The deadline is the absolute TSC value to exit the idle state at. If it
> + * exceeds the global limit in the 'IA32_UMWAIT_CONTROL' register, the global
> + * limit prevails, and the idle state is exited earlier than the deadline.
> + */
> +static inline void umwait_idle(u64 deadline, u32 state)
> +{
> + if (!current_set_polling_and_test()) {
> + u32 eax, edx;
> +
> + eax = lower_32_bits(deadline);
> + edx = upper_32_bits(deadline);
> +
> + __umonitor(¤t_thread_info()->flags);
> + if (!need_resched())
> + __umwait(state, edx, eax);
> + }
> + current_clr_polling();
> +}
> +#else
> +#define umwait_idle(deadline, state) \
> + WARN_ONCE(1, "umwait CPU instruction is not supported")
Please implement the stub as a proper inline.
> +#endif /* CONFIG_X86_64 */
This comment is wrong.
#ifdef CONFIG_X86_64
....
#else /* CONFIG_X86_64 */
#endif /* !CONFIG_X86_64 */
makes it clear what the scope is.
Thanks,
tglx
next prev parent reply other threads:[~2023-06-29 22:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-10 18:35 [PATCH v3 0/3] Sapphire Rapids C0.x idle states support Artem Bityutskiy
2023-06-10 18:35 ` [PATCH v3 1/2] x86/mwait: Add support for idle via umwait Artem Bityutskiy
2023-06-29 19:03 ` Rafael J. Wysocki
2023-06-29 22:04 ` Thomas Gleixner [this message]
2023-06-29 22:36 ` Thomas Gleixner
2023-06-30 16:54 ` Artem Bityutskiy
2023-07-07 17:13 ` Artem Bityutskiy
2023-06-10 18:35 ` [PATCH v3 2/2] intel_idle: add C0.2 state for Sapphire Rapids Xeon Artem Bityutskiy
2023-06-29 22:05 ` [PATCH v3 0/3] Sapphire Rapids C0.x idle states support Thomas Gleixner
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=87352a0vu4.ffs@tglx \
--to=tglx@linutronix.de \
--cc=arjan@linux.intel.com \
--cc=dedekind1@gmail.com \
--cc=linux-pm@vger.kernel.org \
--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