From: Ananth Narayan <firstname.lastname@example.org>
To: email@example.com, firstname.lastname@example.org
Cc: email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH] ACPI: processor_idle: Skip dummy wait for processors based on the Zen microarchitecture
Date: Fri, 23 Sep 2022 21:45:45 +0530 [thread overview]
Message-ID: <email@example.com> (raw)
The MTA mangled your address. So the note is not showing up on the list.
Responding so this hopefully shows up on lkml for the records.
Apologies to everyone else for duplicates.
On 23-09-2022 09:31 pm, AMD\ermorton wrote:
> On 2022-09-21 14:15, David Hansen wrote:
>>> Do X86_FEATURE_ZEN CPUs just have unusually painful
>>> inl(acpi_fadt.xpm_tmr_blk.address) implementations?
> Hi David,
> I'm glad you asked this.
> Obviously the words "painful" and "slow" are arbitrary. But... since there are many aspects such as the platform, core clock frequency, system clock frequency, etc, that play into this, I will refrain from any precise numbers.
> I would say that x86 platforms (that today have in excess of a hundred processors) generally design the legacy PM_TMR and other serial resources in the Southbridge/FCH with the underlying assumption that (a) the kernel accesses them "rarely" in non-performance sensitive code and, more importantly, (b) that it is unlikely to have multiple processors access them "simultaneously". These resources are a fair distant from the processor, and unlike memory controllers, these resources were not designed to have multiple simultaneous accesses running in parallel.
> So let's assert that, to start off with, the accesses are already "slow" from the processor standpoint because of this distance. It is likely that most x86 implementations could easily take around 500ns-1us round trip. The exact number will vary, but a quick sanity test on current x86 production platforms match that for a "singleton" access.
> That alone is well over 1000 core clocks and seems to be reason enough to avoid doing this INL when it is not necessary.
> But as the PM_TMR is not designed to handle simultaneous accesses, if multiple processors do simultaneously access this resource (or even "close to simultaneous"), the first access might be "slow", the second access might be "slower", and well, the 100th access might be "painful". And there are interrupt cases where this can indeed happen - due to this ancient workaround...
> Note that a quick sanity test that we created when we understood this tbench data suggested to me that Intel platforms are not immune from the impact of this worst-case access pattern either. This is not surprising to me. But we did not do an exhaustive check.
> Eric Morton
> AMD Infinity Fabric and SOC Architecture
next prev parent reply other threads:[~2022-09-23 16:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 6:36 [PATCH] ACPI: processor_idle: Skip dummy wait for processors based on the Zen microarchitecture K Prateek Nayak
2022-09-21 8:47 ` Borislav Petkov
2022-09-21 10:39 ` K Prateek Nayak
2022-09-21 13:10 ` Borislav Petkov
2022-09-21 14:15 ` Dave Hansen
2022-09-21 19:51 ` Borislav Petkov
2022-09-21 19:55 ` Limonciello, Mario
2022-09-22 3:58 ` Ananth Narayan
2022-09-22 5:44 ` K Prateek Nayak
[not found] ` <firstname.lastname@example.org>
2022-09-23 16:15 ` Ananth Narayan [this message]
2022-09-21 15:00 ` Peter Zijlstra
2022-09-21 19:48 ` Borislav Petkov
2022-09-22 8:17 ` Peter Zijlstra
2022-09-22 15:21 ` Rafael J. Wysocki
2022-09-22 15:36 ` Borislav Petkov
2022-09-22 15:53 ` Rafael J. Wysocki
2022-09-22 16:36 ` Dave Hansen
2022-09-22 16:44 ` Dave Hansen
2022-09-22 16:54 ` K Prateek Nayak
2022-09-22 17:01 ` Dave Hansen
2022-09-22 17:48 ` Limonciello, Mario
2022-09-22 18:17 ` Dave Hansen
2022-09-22 18:28 ` Limonciello, Mario
2022-09-23 11:47 ` Ananth Narayan
2022-09-22 19:42 ` Andreas Mohr
2022-09-22 20:10 ` Andreas Mohr
2022-09-22 21:21 ` Dave Hansen
2022-09-22 21:38 ` Limonciello, Mario
2022-09-23 7:42 ` Peter Zijlstra
2022-09-23 7:57 ` Peter Zijlstra
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.