From: Fenghua Yu <fenghua.yu@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
Peter Newman <peternewman@google.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"H . Peter Anvin" <hpa@zytor.com>,
"Babu Moger" <babu.moger@amd.com>,
James Morse <james.morse@arm.com>,
"Martin Kletzander" <nert.pinx@gmail.com>,
Shaopeng Tan <tan.shaopeng@fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eranian, Stephane" <eranian@google.com>
Subject: Re: [PATCH 2/2] x86/resctrl: Don't workqueue local event counter reads
Date: Mon, 4 Nov 2024 19:29:00 -0800 [thread overview]
Message-ID: <2e2636ef-eb0f-067d-ef8b-a95e762dbf9f@intel.com> (raw)
In-Reply-To: <SJ1PR11MB6083901BDDB4B6F8733977B9FC522@SJ1PR11MB6083.namprd11.prod.outlook.com>
Hi, Tony,
On 11/4/24 16:12, Luck, Tony wrote:
>> Whenever this function is called, the performance is degraded rather
>> than improved because extra get_cpu()/put_cpu() are called in the fast
>> path in the current patch.
>
> But get_cpu()/put_cpu() aren't high overhead. Maybe costs less that the
> cpumask_any_housekeeping() call that is avoided by Peter's patch.
Quote from Peter:
"AMD EPYC 7B12 64-Core Processor (250 mon groups)
Local Domain: 3.25M -> 1.22M (-62.5%)
Remote Domain: 7.91M -> 8.05M (+2.9%)
Intel(R) Xeon(R) Gold 6268CL CPU @ 2.80GHz (190 mon groups)
Local Domain: 2.98M -> 2.21M (-25.8%)
Remote Domain: 4.49M -> 4.62M (+3.1%)
Note that there is a small increase in overhead for remote domains,
which results from the introduction of a put_cpu() call to reenable
preemption after determining whether the fast path can be used."
As his data shows, if the fast path is not taken, the extra put_cpu()
itself costs +2.9% extra time on AMD machine and +3.1% extra time on
Intel machine.
And this ~3% overhead is on top of queued work, which is more expensive
than cpumask_any_housekeeping() IIUC.
>
> Note that if Peter's patch doesn't take its fast path because the calling
> CPU was on the wrong domain, then the subsequent code is going to
> do an IPI whichever of the if/else path is taken.
In this case, actually IPI is only taken in smp_call_function_any() and
smp_call_on_cpu() invokes a queued work instead of IPI.
My proposed change logically doesn't change Peter's fast path and
performance for nohz_full/smp_call_on_cpu() case. It just utilizes the
"built-in fast path already" inside smp_call_function_any() to save
extra get_cpu() and put_cpu(). Hopefully the saved extra get_cpu() and
put_cpu() can offset cost of cpumask_any_housekeeping().
From Peter's commit message, seems nohz_full case is not
called/measured a lot if any. If only one or a very few housekeeping
CPUs on a large system, the nohz_full case will be called frequently and
fast path will fail most of time and the extra get_cpu()/put_cpu()
around the fast path might impact more on both local and total domain.
Thanks.
-Fenghua
next prev parent reply other threads:[~2024-11-05 3:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-31 14:25 [PATCH 1/2] selftests/resctrl: fastcat for benchmarking counter reads Peter Newman
2024-10-31 14:25 ` [PATCH 2/2] x86/resctrl: Don't workqueue local event " Peter Newman
2024-11-01 18:35 ` Luck, Tony
2024-11-04 22:36 ` Fenghua Yu
2024-11-04 22:56 ` Luck, Tony
2024-11-04 23:59 ` Fenghua Yu
2024-11-05 0:12 ` Luck, Tony
2024-11-05 3:29 ` Fenghua Yu [this message]
2024-11-05 11:25 ` Peter Newman
2024-11-05 23:20 ` Reinette Chatre
2024-11-05 23:39 ` Luck, Tony
2024-11-06 0:13 ` Reinette Chatre
2024-11-06 9:42 ` Peter Newman
2024-11-06 17:12 ` Luck, Tony
2024-11-06 15:52 ` Peter Newman
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=2e2636ef-eb0f-067d-ef8b-a95e762dbf9f@intel.com \
--to=fenghua.yu@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nert.pinx@gmail.com \
--cc=peternewman@google.com \
--cc=reinette.chatre@intel.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@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.