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 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.