From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752099AbdBMKhk (ORCPT ); Mon, 13 Feb 2017 05:37:40 -0500 Received: from mout.web.de ([217.72.192.78]:58677 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbdBMKhi (ORCPT ); Mon, 13 Feb 2017 05:37:38 -0500 Subject: Re: IB/hfi1: Adjust another size determination in hfi1_user_sdma_alloc_queues() To: Johannes Thumshirn , linux-rdma@vger.kernel.org References: <8a997282-09c7-0f9f-645e-d7c6e8c79e67@users.sourceforge.net> <0fdf4d81-58d7-c6fc-b37f-41d47675dd83@users.sourceforge.net> <4dca91c1-488d-120d-bd25-74f400242bd2@users.sourceforge.net> <9ce8c7b1-1ae5-fe15-2740-b4f7653555c4@suse.de> Cc: Dennis Dalessandro , Doug Ledford , Hal Rosenstock , Mike Marciniszyn , Sean Hefty , LKML , kernel-janitors@vger.kernel.org From: SF Markus Elfring Message-ID: <8ec653df-9d73-3c94-9559-7a732417e578@users.sourceforge.net> Date: Mon, 13 Feb 2017 11:37:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9ce8c7b1-1ae5-fe15-2740-b4f7653555c4@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:XVSi9b9EoKhBECULV6AKo+tzuR0H2gDzW9gy2YJD4wxwRwCuxQ9 WIan/cbJg17djmD6VTPkodbzS1JiH/jJaH+eM8kQwJgpxk9M2Rx25NVM6Zp0z3rag5W5s/1 LLTZLzBBuYM+3mc2XSjxNPdfVZEywh0E5LlUKhgs+rQWgFZdHPEEjugDQKvfWnVF9qXebpT ghMUBKF+Hk1hR+qdEc5Ag== X-UI-Out-Filterresults: notjunk:1;V01:K0:L2KzKGFSAV0=:a8caQdmjktmJiot/DMbOLZ sVD5cgg/RmpvMqjOvwstQ2dRPCeB2S/bBfVVCiY09loC6+owiNykg1LjJ9vFKCSbGKUWpFkLH jQE2FZ7rpPfoTjYpJKiFxL8uWWzuvAHRhrvos21lM3tb53m+4cNmQBjwBEu3gZrQzWRBZx+XD llCAG9fZO1qggp2dItgfM3sGk5H357C0JrVpKmVJtFN4CuEy1KLkRpg9GKrWGE9sxXxAEitXa AcqVxN2vx7oVhHp84wnbMcONBMKLP8IX6bLTgXHRFWdVgC3vHnnFWoS5Dms9rtopEXvsUrk8v HUAsnV1km0raj7RM/+3+irflFjpmPPa3YUc4pVU9lQtpOBmaZmxc+XibuhH1O0gXawnGQYR5l 377R+xDKJgM8Y3NP4sucsbV2XsDNM0ogm532Qse5c1l6uVac2g6kysLMXgQHN6/FwXVjxeW8M Bm8TZm2Vs3cMBUHOYHlbPuUNxop3Rq1/rVNBZZ5LjD+dJKm+LQJHQxwOVcBykrzHmEBLXHiai GPcAjhEDI4BcJGvxkTrooDYKWvFP0j0y/785p03BOgDJfQarX1YLjKELQRPe6K0V+JzgT27M5 LBz3LYJSeXflIxNDL+fEBtbm3x5GoN/mmu3TNqPhM8TH5gaXCck5aGpgznnbNpXi9e7L7TLgP YjI/HMogtqWjmUMo+71VJhwmA3qZLRAQcM+/G/Dm3ee6e7Ne8abMu78W462Bj3DIoEUIkS91q 2cDjWjZsbn3ABO7ANkBMxvUlvo+frmXsVwkVHljbZ6zHCTzWAK232Pboa3wbPd4CtRKSyQymE SJAaNSY Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> How often does it really make sense to keep such a product in this local variable? > > It depends. Lets take it the other way round. If I this in a review I'd > suggest the submitter to create a local variable for the multiplication > to get rid of the line break. It's avoidable. I imagine that there are further possibilities to improve the involved programming for various arrays. > And again, the compiler will optimize it away. > > Apart from the fact that you haven't tested your patch at all: This is true in principle as I could compile the source code adjustment at least. > jthumshirn@linux-x5ow:linux (test)$ git am ~/\[PATCH\ 3_5\]\ IB_hfi1\:\ > Adjust\ another\ size\ determination\ in\ > hfi1_user_sdma_alloc_queues\(\).eml > Applying: IB/hfi1: Adjust another size determination in > hfi1_user_sdma_alloc_queues() > jthumshirn@linux-x5ow:linux (test)$ make > drivers/infiniband/hw/hfi1/user_sdma.o CHK > include/config/kernel.release > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CHK include/generated/bounds.h > CHK include/generated/timeconst.h > CHK include/generated/asm-offsets.h > CALL scripts/checksyscalls.sh > CC drivers/infiniband/hw/hfi1/user_sdma.o > drivers/infiniband/hw/hfi1/user_sdma.c: In function > ‘hfi1_user_sdma_alloc_queues’: > drivers/infiniband/hw/hfi1/user_sdma.c:402:2: error: ‘memsize’ > undeclared (first use in this function) > memsize = sizeof(*pq->reqs) * hfi1_sdma_comp_ring_size; > ^ How do you think about to apply also the previous update step like “[PATCH 2/5] IB/hfi1: Use kcalloc() in hfi1_user_sdma_alloc_queues()”? > So to sum up: there is no evident improvement in the resulting binary There might not be a remarkable difference with the default software build parameters. > and you introduce a stylistic glitch (the new line break in a function call). There are different opinions about this implementation detail, aren't there? Regards, Markus