[PATCH v2 01/13] selftests/resctrl: Convert get_mem_bw_imc() fd close to for loop

Ilpo Järvinen posted 13 patches 1 year, 11 months ago
There is a newer version of this series
[PATCH v2 01/13] selftests/resctrl: Convert get_mem_bw_imc() fd close to for loop
Posted by Ilpo Järvinen 1 year, 11 months ago
The open() side handles fds in a for loop but close() is based on two
fixed indexes READ and WRITE.

Match the close() side with the open() side by using for loop for
consistency.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
 tools/testing/selftests/resctrl/resctrl_val.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/resctrl/resctrl_val.c b/tools/testing/selftests/resctrl/resctrl_val.c
index 5a49f07a6c85..36139cba7be8 100644
--- a/tools/testing/selftests/resctrl/resctrl_val.c
+++ b/tools/testing/selftests/resctrl/resctrl_val.c
@@ -368,10 +368,9 @@ static int get_mem_bw_imc(int cpu_no, char *bw_report, float *bw_imc)
 		writes += w->return_value.value * of_mul_write * SCALE;
 	}
 
-	for (imc = 0; imc < imcs; imc++) {
-		close(imc_counters_config[imc][READ].fd);
-		close(imc_counters_config[imc][WRITE].fd);
-	}
+	for (imc = 0; imc < imcs; imc++)
+		for (j = 0; j < 2; j++)
+			close(imc_counters_config[imc][j].fd);
 
 	if (strcmp(bw_report, "reads") == 0) {
 		*bw_imc = reads;
-- 
2.39.2

Re: [PATCH v2 01/13] selftests/resctrl: Convert get_mem_bw_imc() fd close to for loop
Posted by Reinette Chatre 1 year, 10 months ago
Hi Ilpo,

On 3/11/2024 6:52 AM, Ilpo Järvinen wrote:
> The open() side handles fds in a for loop but close() is based on two
> fixed indexes READ and WRITE.
> 
> Match the close() side with the open() side by using for loop for
> consistency.

I find the close() side to be more appropriate. I say this for two
reasons: (a) looking at the close() calls as they are now it is
obvious what the close() applies to and transitioning to a loop
adds a layer of unnecessary indirection, (b) I do not think a loop
is appropriate for the READ/WRITE define that just happen to be 0
and 1 ... there should not be an assumption about their underlying
value.

Reinette
Re: [PATCH v2 01/13] selftests/resctrl: Convert get_mem_bw_imc() fd close to for loop
Posted by Ilpo Järvinen 1 year, 10 months ago
On Tue, 19 Mar 2024, Reinette Chatre wrote:
> On 3/11/2024 6:52 AM, Ilpo Järvinen wrote:
> > The open() side handles fds in a for loop but close() is based on two
> > fixed indexes READ and WRITE.
> > 
> > Match the close() side with the open() side by using for loop for
> > consistency.
> 
> I find the close() side to be more appropriate. I say this for two
> reasons: (a) looking at the close() calls as they are now it is
> obvious what the close() applies to and transitioning to a loop
> adds a layer of unnecessary indirection, (b) I do not think a loop
> is appropriate for the READ/WRITE define that just happen to be 0
> and 1 ... there should not be an assumption about their underlying
> value.

Hi,

So to confirm are you suggesting I should remove all the other loops 
instead?

-- 
 i.
Re: [PATCH v2 01/13] selftests/resctrl: Convert get_mem_bw_imc() fd close to for loop
Posted by Ilpo Järvinen 1 year, 10 months ago
On Fri, 22 Mar 2024, Ilpo Järvinen wrote:

> On Tue, 19 Mar 2024, Reinette Chatre wrote:
> > On 3/11/2024 6:52 AM, Ilpo Järvinen wrote:
> > > The open() side handles fds in a for loop but close() is based on two
> > > fixed indexes READ and WRITE.
> > > 
> > > Match the close() side with the open() side by using for loop for
> > > consistency.
> > 
> > I find the close() side to be more appropriate. I say this for two
> > reasons: (a) looking at the close() calls as they are now it is
> > obvious what the close() applies to and transitioning to a loop
> > adds a layer of unnecessary indirection, (b) I do not think a loop
> > is appropriate for the READ/WRITE define that just happen to be 0
> > and 1 ... there should not be an assumption about their underlying
> > value.
> 
> Hi,
> 
> So to confirm are you suggesting I should remove all the other loops 
> instead?

Nevermind, I read the comment to second patch, so the answer is yes. :-)

-- 
 i.