[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083901BDDB4B6F8733977B9FC522@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Tue, 5 Nov 2024 00:12:34 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Yu, Fenghua" <fenghua.yu@...el.com>, Peter Newman
<peternewman@...gle.com>, "Chatre, Reinette" <reinette.chatre@...el.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, "Babu
Moger" <babu.moger@....com>, James Morse <james.morse@....com>, "Martin
Kletzander" <nert.pinx@...il.com>, Shaopeng Tan <tan.shaopeng@...itsu.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Eranian,
Stephane" <eranian@...gle.com>
Subject: RE: [PATCH 2/2] x86/resctrl: Don't workqueue local event counter
reads
> 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.
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.
-Tony
Powered by blists - more mailing lists