Date:   Tue, 14 Feb 2023 12:00:41 +0200 (EET)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     Reinette Chatre <reinette.chatre@intel.com>
cc:     linux-kselftest@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH 2/4] selftests/resctrl: Don't hard code divisor in MBM
 results
In-Reply-To: <8ed0dcbd-86af-2658-95de-fdccffba7728@intel.com>
Message-ID: <346283c6-b5a5-ad35-7a90-fd17858be46f@linux.intel.com>
References: <20230208094026.22529-1-ilpo.jarvinen@linux.intel.com> <20230208094026.22529-3-ilpo.jarvinen@linux.intel.com> <8ed0dcbd-86af-2658-95de-fdccffba7728@intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-941652853-1676368845=:1771"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-941652853-1676368845=:1771
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT

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@intel.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.

--8323329-941652853-1676368845=:1771--