Hi Ilpo,
On 9/30/24 6:52 AM, Ilpo Järvinen wrote:
On Thu, 12 Sep 2024, Reinette Chatre wrote:
diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h index 51f5f4b25e06..ba1ce1b35699 100644 --- a/tools/testing/selftests/resctrl/resctrl.h +++ b/tools/testing/selftests/resctrl/resctrl.h @@ -142,7 +142,7 @@ int perf_event_open(struct perf_event_attr *hw_event, pid_t pid, int cpu, unsigned char *alloc_buffer(size_t buf_size, int memflush); void mem_flush(unsigned char *buf, size_t buf_size); void fill_cache_read(unsigned char *buf, size_t buf_size, bool once); -int run_fill_buf(size_t buf_size, int memflush, int op); +int run_fill_buf(size_t buf_size, int memflush); int initialize_mem_bw_imc(void); int measure_mem_bw(const struct user_params *uparams, struct resctrl_val_param *param, pid_t bm_pid, diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c b/tools/testing/selftests/resctrl/resctrl_tests.c index bee4123a5a9b..60627dbae20a 100644 --- a/tools/testing/selftests/resctrl/resctrl_tests.c +++ b/tools/testing/selftests/resctrl/resctrl_tests.c @@ -265,13 +265,16 @@ int main(int argc, char **argv) ksft_exit_fail_msg("Out of memory!\n"); uparams.benchmark_cmd[1] = span_str; uparams.benchmark_cmd[2] = "1";
uparams.benchmark_cmd[3] = "0";
* Third parameter was previously used for "operation"* (read/write) of which only (now default) "read"/"0"* works.*/
- Fourth parameter was previously used to indicate
- how long "fill_buf" should run for, with "false"
- ("fill_buf" will keep running until terminated)
- the only option that works.
uparams.benchmark_cmd[3] = NULL;The same question as with the previous patch, why is [4] = NULL kept around?
You are correct that functionally this is not required. If this parameter disappears at this point then there is no record of parameter 4 ever being used. Even though this is user space I do still have my kernel view that we should aim to maintain ABI. This means that parameter 4 will always be "used" to indicate how long fill_buf should run for and if "fill_buf" ever needs a new parameter, it cannot use parameter 4 since that already has a meaning. While the above may seem unnecessary, I think it makes the more robust parameter processing found in patch #9 that replaces it easier to understand. In that patch the comments above are coded to ensure parameter values are as expected and parameter 4 continue to be dedicated to how long "fill_buf" should run for.
As you mention in similar feedback to patch #6, the [5] assignment is also unnecessary. Since it is just used as termination I can remove it.
Reinette