[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083C75727F30800AFC7A1C9FCDDA@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 26 Oct 2023 22:59:32 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "babu.moger@....com" <babu.moger@....com>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"Peter Newman" <peternewman@...gle.com>,
Jonathan Corbet <corbet@....net>,
Shuah Khan <skhan@...uxfoundation.org>,
"x86@...nel.org" <x86@...nel.org>
CC: Shaopeng Tan <tan.shaopeng@...itsu.com>,
James Morse <james.morse@....com>,
Jamie Iles <quic_jiles@...cinc.com>,
Randy Dunlap <rdunlap@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH v3] x86/resctrl: mba_MBps: Fall back to total b/w if local
b/w unavailable
>> static void mbm_bw_count(u32 rmid, struct rmid_read *rr)
>> {
>> - struct mbm_state *m = &rr->d->mbm_local[rmid];
>> + enum resctrl_event_id mba_mbps_evt_id = pick_mba_mbps_event();
>
> How about evt_id instead of mba_mbps_evt_id? It seems pretty mouthful
> for temp variable.
Sure. The long name made sense as a globa. But as you say, a temp
variable doesn't need to be so verbose. Context from being initialized
by the pick_mba_mbps_event() function also helps reader to see what
it is used for.
I'll make that change if others vote for the v3 approach over v2.
-Tony
Powered by blists - more mailing lists