Hi Ilpo,
On 10/4/24 7:29 AM, Ilpo Järvinen wrote:
> On Thu, 12 Sep 2024, Reinette Chatre wrote:
...
>> diff --git a/tools/testing/selftests/resctrl/mbm_test.c b/tools/testing/selftests/resctrl/mbm_test.c
>> index 7635ee6b9339..8c818e292dce 100644
>> --- a/tools/testing/selftests/resctrl/mbm_test.c
>> +++ b/tools/testing/selftests/resctrl/mbm_test.c
>> @@ -22,17 +22,13 @@ show_bw_info(unsigned long *bw_imc, unsigned long *bw_resc, size_t span)
>> int runs, ret, avg_diff_per;
>> float avg_diff = 0;
>>
>> - /*
>> - * Discard the first value which is inaccurate due to monitoring setup
>> - * transition phase.
>> - */
>> - for (runs = 1; runs < NUM_OF_RUNS ; runs++) {
>> + for (runs = 0; runs < NUM_OF_RUNS; runs++) {
>> sum_bw_imc += bw_imc[runs];
>> sum_bw_resc += bw_resc[runs];
>> }
>>
>> - avg_bw_imc = sum_bw_imc / 4;
>> - avg_bw_resc = sum_bw_resc / 4;
>> + avg_bw_imc = sum_bw_imc / NUM_OF_RUNS;
>> + avg_bw_resc = sum_bw_resc / NUM_OF_RUNS;
>> avg_diff = (float)labs(avg_bw_resc - avg_bw_imc) / avg_bw_imc;
>> avg_diff_per = (int)(avg_diff * 100);
>
> While the patch itself is fine, I notice the code has this magic number
> gem too:
>
> unsigned long bw_imc[1024], bw_resc[1024];
That could be related to NUM_OF_RUNS ... I'll take a look. While this is safe
since both array size and number of runs are hardcoded in test, of course
you are right that this can improved.
I'm also concerned about something like below where there are some
assumptions of external data ... not that we expect the kernel
interface to change, but something like below should be more robust:
static int read_from_imc_dir(char *imc_dir, int count)
{
char cas_count_cfg[1024],...
...
if (fscanf(fp, "%s", cas_count_cfg) <= 0) { /* May read more than 1024 */
...
}
}
>
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
Thank you very much for your review. Much appreciated.
Reinette
