[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <346283c6-b5a5-ad35-7a90-fd17858be46f@linux.intel.com>
Date: Tue, 14 Feb 2023 12:00:41 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Reinette Chatre <reinette.chatre@...el.com>
cc: linux-kselftest@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
Fenghua Yu <fenghua.yu@...el.com>,
Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH 2/4] selftests/resctrl: Don't hard code divisor in MBM
results
On Mon, 13 Feb 2023, Reinette Chatre wrote:
> Hi Ilpo,
>
> The subject is "Don't hard code divisor ..." yet it seems to me
> that the hard coding persists. It is just changed from a magic
> constant to a macro.
Yeah, it was a bad wording.
> On 2/8/2023 1:40 AM, Ilpo Järvinen wrote:
> > From: Fenghua Yu <fenghua.yu@...el.com>
> >
> > Presently, while calculating MBM results, the divisor is hard coded as 4.
>
> "Presently" can be removed. Here and in the rest of the series the usage of
> "presently" and "currently" can usually be removed to improve clarity.
>
> > It's hard coded to 4 because "NUM_OF_RUNS" is defined as 5 and the test
> > does not count first result and hence 4. So, instead of hard coding the
> > value to 4, change it to NUM_OF_RUNS - 1.
>
> Are there any plans surrounding using struct resctrl_val_param::num_of_runs
> instead?
Actually no.
What I'd want to do is that the functions which call these result
calculator functions would specify the number of tests they passed
into the result calculator. It seems safer because the results are read
back from a file which could have changed (or got deleted due to an
ipc bug prematurely cleaning up the file) and would better take account
those cases where the first value is skipped when reading the results.
I think I'll drop this patch for now.
--
i.
Powered by blists - more mailing lists