Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Fri, 27 Oct 2023 13:32:31 +0200
From:   Maciej =?utf-8?Q?Wiecz=C3=B3r-Retman?= 
        <maciej.wieczor-retman@intel.com>
To:     Ilpo =?utf-8?B?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>
CC:     <linux-kselftest@vger.kernel.org>,
        Reinette Chatre <reinette.chatre@intel.com>,
        Shuah Khan <shuah@kernel.org>,
        Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 02/24] selftests/resctrl: Refactor fill_buf functions
Message-ID: <v5jdxr2sayffhq5sslyn2f5x6ogynosuhjxgdmfwzwdpvejngu@aahvjgz3sqcp>
References: <20231024092634.7122-1-ilpo.jarvinen@linux.intel.com>
 <20231024092634.7122-3-ilpo.jarvinen@linux.intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20231024092634.7122-3-ilpo.jarvinen@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?I5UZpOdDM8IfcWc1r61VnFEhUmdWLOTbPH4RDzTW22dMnaEnvPw+2AvKOD?=
 =?iso-8859-1?Q?NWV8nYAygF7NzFy7pq5w9g6r4Mg9EI6m4WnoUE4IC3R4tS+KX1N4nqSTvZ?=
 =?iso-8859-1?Q?46y8cVvGxvfFlq9CHTGuuoy2+wf+w+19++heNQtTDNqoSWTFkTD1j4X0tA?=
 =?iso-8859-1?Q?ZuVLgB4mVwxtbrhFK2wyB+3mKJ59FwedjSw7nxNr/nVzWaYZ3/1q1GAwtl?=
 =?iso-8859-1?Q?VHMeME1FkyUY/XEC59D3vyjdAuARx2DnWTQiFCeMYpcVooZr6eU4ZfEUz1?=
 =?iso-8859-1?Q?SuW7RZCOcdYSxttwDBeqIkNBVHDGFD8oeGe+K8nblSmqsRH7aDp3TYeaob?=
 =?iso-8859-1?Q?KYXPcdzr5uqD3gJ9E1FDcGq/+Qo4QBApLvE7mvCaw6N0B+ag6s+YR/slmr?=
 =?iso-8859-1?Q?GDjL3Zs3J25eXqyUbbWZCYN6fv+UJS7OUUPP0WaIgunR1NjOkFiU0/GGiJ?=
 =?iso-8859-1?Q?UfFRGlE0dncoBQxW3Crhb+tuc1rMsGw1JJ7Ch6RR9F+av+nlbf3g9U52z9?=
 =?iso-8859-1?Q?YQWhO3tEjU67B/DDCA2UYT2kPQOvWdaqPDQDqVyZVWmC6QnbUiJc+rHD9E?=
 =?iso-8859-1?Q?JdnfuqBAgeqUlMZaqHOt4WhUFKydJL0GwV9nbCkgrI15ATaJRUKBXKm6w+?=
 =?iso-8859-1?Q?wp35MVP7RvleG1hor+zjdMJ7FAJfdexHXnf0FvOdRvv+0YNmvD0fk60aZJ?=
 =?iso-8859-1?Q?h+DfQl0T0ky/T3acnnjQSO+JX351X5xwCgWBlkZEKNU8z4/cTZ3Kp77/dW?=
 =?iso-8859-1?Q?hCdHtHSdiRjNAqG1Ajea2Y3h+kzrkg8EC8W+VIeh5G0EPt0ydryaEPkBIl?=
 =?iso-8859-1?Q?JHQ9kT2ly4iU0TceY/8dPiV+QSfooW8BS4amvEoTe71gcgJ31Z+wqQAUVS?=
 =?iso-8859-1?Q?3IUv++A4830DbDsDD9CqqZWoZbJJb8Z6plOEhQmzoaGuIeCfT8kMSkCNSA?=
 =?iso-8859-1?Q?G2K9UhQOvLcSVqMacTdgvQ9N67uJzTQVn+27fqwR1vSAMbHvMrmUDC8NxT?=
 =?iso-8859-1?Q?tN7v/6jGcHOmjf3GxMzXWlpQrJsbwmqr26lEww/q7QDToFv5CVkOBmDVj8?=
 =?iso-8859-1?Q?G2NtS86j7iXTfagoHulwJtGvmEbylq0sy5ZRKkSBLmU88/LiTUfYmkdjZo?=
 =?iso-8859-1?Q?B58ypROxBDRdKNdhCuue08p9w545A1FE9BcWr3e2AAX65Pc+BR78Mlnqf8?=
 =?iso-8859-1?Q?e2xaMFg77l9l+Mn02VlA7FaR638SZ5m5yFRD/+RJJA/uE/007fhoTDtfge?=
 =?iso-8859-1?Q?gOMlN9MStf2lqcz6Hd6bsyYxEhmBTgenxySoFt/9We9oHxN8WNXmZZfR9n?=
 =?iso-8859-1?Q?2vTsuf7w1jBDYSRvvdJ3VhdbpjCEhoQVbZlodaPqnlWENc+1JQxjTkTnIf?=
 =?iso-8859-1?Q?yFeaH+9P/WtaJCPvj3Wy9ey2W2Rdo8y+MyC4INljne2+KSyybr2roIcaAy?=
 =?iso-8859-1?Q?69BPZ3uCxJek6Z1RcAogI7+f++8ephU6+YiBXB/VNF0UvF3iclPJRefUWs?=
 =?iso-8859-1?Q?SndTNmUnnGBYBTSh4dyQMn+lxM6wM/ys7YOck+qUFEITj97mxQsdkhZwSS?=
 =?iso-8859-1?Q?Zy1G74aDeMglwf61zUVJVyLHP+ZHI703fe1vfbtJ4FawQLtjR+OtlunUnn?=
 =?iso-8859-1?Q?LjguqC8UrhkKUbbq3pYj5wMFEohsQWWWELQgBlD+u2R0XlIWucsMCWsLEg?=
 =?iso-8859-1?Q?fc4lhA9TmKXf+ytoR4k=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 76596a66-bb53-4462-6c69-08dbd6e06b52
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6231.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2023 11:32:36.6673
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gr+C/QfmXN7ifcS9G7qUAskNeqQ5YYvy/mGacttmCigWYhiBl8bc8hOMGKtOp2C0OYf3N+W+Q/LVVKM/hRkfpsQ7A4VfbeGxUBZMk1ZY0cw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5893
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 27 Oct 2023 04:32:57 -0700 (PDT)

On 2023-10-24 at 12:26:12 +0300, Ilpo J?rvinen wrote:
>There are unnecessary nested calls in fill_buf.c:
>  - run_fill_buf() calls fill_cache()
>  - alloc_buffer() calls malloc_and_init_memory()
>
>Simplify the code flow and remove those unnecessary call levels by
>moving the called code inside the calling function.
>
>Resolve the difference in run_fill_buf() and fill_cache() parameter
>name into 'buf_size' which is more descriptive than 'span'.
>
>Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen@linux.intel.com>
>---
> tools/testing/selftests/resctrl/fill_buf.c | 58 +++++++---------------
> tools/testing/selftests/resctrl/resctrl.h  |  2 +-
> 2 files changed, 20 insertions(+), 40 deletions(-)
>
>diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
>index f9893edda869..9d0b0bf4b85a 100644
>--- a/tools/testing/selftests/resctrl/fill_buf.c
>+++ b/tools/testing/selftests/resctrl/fill_buf.c
>@@ -51,29 +51,6 @@ static void mem_flush(unsigned char *buf, size_t buf_size)
> 	sb();
> }
> 
>-static void *malloc_and_init_memory(size_t buf_size)
>-{
>-	void *p = NULL;
>-	uint64_t *p64;
>-	size_t s64;
>-	int ret;
>-
>-	ret = posix_memalign(&p, PAGE_SIZE, buf_size);
>-	if (ret < 0)
>-		return NULL;
>-
>-	p64 = (uint64_t *)p;
>-	s64 = buf_size / sizeof(uint64_t);
>-
>-	while (s64 > 0) {
>-		*p64 = (uint64_t)rand();
>-		p64 += (CL_SIZE / sizeof(uint64_t));
>-		s64 -= (CL_SIZE / sizeof(uint64_t));
>-	}
>-
>-	return p;
>-}
>-
> static int fill_one_span_read(unsigned char *buf, size_t buf_size)
> {
> 	unsigned char *end_ptr = buf + buf_size;
>@@ -137,20 +114,33 @@ static int fill_cache_write(unsigned char *buf, size_t buf_size, bool once)
> 
> static unsigned char *alloc_buffer(size_t buf_size, int memflush)
> {
>-	unsigned char *buf;
>+	void *p = NULL;

Is this initialization doing anything? "p" seems to be either overwritten or in
case of an error never accessed.

>+	uint64_t *p64;
>+	size_t s64;
>+	int ret;
> 
>-	buf = malloc_and_init_memory(buf_size);
>-	if (!buf)
>+	ret = posix_memalign(&p, PAGE_SIZE, buf_size);
>+	if (ret < 0)
> 		return NULL;
> 
>+	/* Initialize the buffer */
>+	p64 = (uint64_t *)p;
>+	s64 = buf_size / sizeof(uint64_t);
>+
>+	while (s64 > 0) {
>+		*p64 = (uint64_t)rand();
>+		p64 += (CL_SIZE / sizeof(uint64_t));
>+		s64 -= (CL_SIZE / sizeof(uint64_t));
>+	}
>+
> 	/* Flush the memory before using to avoid "cache hot pages" effect */
> 	if (memflush)
>-		mem_flush(buf, buf_size);
>+		mem_flush(p, buf_size);

Wouldn't renaming "p" to "buf" keep this relationship with "buf_size" more
explicit?

Or is naming void pointers "buffers" not appropriate?

> 
>-	return buf;
>+	return p;
> }

-- 
Kind regards
Maciej Wiecz?r-Retman