[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB608357ED39FA4FA1C85C6DB2FC512@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 4 Nov 2024 22:56:32 +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
> cpu = cpumask_any_housekeeping(cpumask, RESCTRL_PICK_ANY_CPU);
To a large degree Peter's is working around inefficiency in this housekeeping
call.
Code may be running on a suitable CPU from the domain cpumask, but this
call will very likely pick the first CPU in that mask, rather than the current one.
From that point it's all downhill unless you are lucky enough that the first
CPU is a tick_nohz_full_cpu() one and you take the
smp_call_function_any(cpumask, mon_event_count, rr, 1);
path. It seems that on many systems you'll take the
smp_call_on_cpu(cpu, smp_mon_event_count, rr, false);
path and make a pointless IPI to get the data.
-Tony
Powered by blists - more mailing lists