From: Johannes Thumshirn <jthumshirn@suse.de>
To: SF Markus Elfring <elfring@users.sourceforge.net>,
linux-rdma@vger.kernel.org
Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>,
Doug Ledford <dledford@redhat.com>,
Hal Rosenstock <hal.rosenstock@gmail.com>,
Mike Marciniszyn <mike.marciniszyn@intel.com>,
Sean Hefty <sean.hefty@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 3/5] IB/hfi1: Adjust another size determination in hfi1_user_sdma_alloc_queues()
Date: Mon, 13 Feb 2017 10:51:53 +0100 [thread overview]
Message-ID: <9ce8c7b1-1ae5-fe15-2740-b4f7653555c4@suse.de> (raw)
In-Reply-To: <4dca91c1-488d-120d-bd25-74f400242bd2@users.sourceforge.net>
On 02/13/2017 10:32 AM, SF Markus Elfring wrote:
>>> @@ -443,8 +442,8 @@ int hfi1_user_sdma_alloc_queues(struct hfi1_ctxtdata *uctxt, struct file *fp)
>>> if (!cq)
>>> goto cq_nomem;
>>>
>>> - memsize = PAGE_ALIGN(sizeof(*cq->comps) * hfi1_sdma_comp_ring_size);
>>> - cq->comps = vmalloc_user(memsize);
>>> + cq->comps = vmalloc_user(PAGE_ALIGN(sizeof(*cq->comps)
>>> + * hfi1_sdma_comp_ring_size));
>>> if (!cq->comps)
>>> goto cq_comps_nomem;
>>>
>>>
>>
>> IMHO this makes readability worse.
>
> 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. And again, the compiler
will optimize it away.
Apart from the fact that you haven't tested your patch at all:
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;
^
drivers/infiniband/hw/hfi1/user_sdma.c:402:2: note: each undeclared
identifier is reported only once for each function it appears in
scripts/Makefile.build:294: recipe for target
'drivers/infiniband/hw/hfi1/user_sdma.o' failed
make[1]: *** [drivers/infiniband/hw/hfi1/user_sdma.o] Error 1
Makefile:1640: recipe for target
'drivers/infiniband/hw/hfi1/user_sdma.o' failed
make: *** [drivers/infiniband/hw/hfi1/user_sdma.o] Error 2
With this fixed:
jthumshirn@linux-x5ow:linux (test)$ size
drivers/infiniband/hw/hfi1/user_sdma.o.*
text data bss dec hex filename
15393 212 292 15897 3e19
drivers/infiniband/hw/hfi1/user_sdma.o.old
15393 212 292 15897 3e19
drivers/infiniband/hw/hfi1/user_sdma.o.patched
Glancing over the diff of the objdump of these two object files you'll
notice that all your patch is doing is moving the code around in the
.text section of the binary.
So to sum up: there is no evident improvement in the resulting binary
and you introduce a stylistic glitch (the new line break in a function
call).
But all of what I've provided above would have been your job as patch
submitter. You have to reason why your patch is good, it's not our job
to reason why it's bad.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
next prev parent reply other threads:[~2017-02-13 9:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 21:00 [PATCH 0/5] IB/hfi1: Fine-tuning for three function implementations SF Markus Elfring
2017-02-10 21:01 ` [PATCH 1/5] IB/hfi1: Use kcalloc() in hfi1_user_exp_rcv_init() SF Markus Elfring
2017-02-10 21:02 ` [PATCH 2/5] IB/hfi1: Use kcalloc() in hfi1_user_sdma_alloc_queues() SF Markus Elfring
2017-02-10 21:03 ` [PATCH 3/5] IB/hfi1: Adjust another size determination " SF Markus Elfring
2017-02-13 9:10 ` Johannes Thumshirn
2017-02-13 9:32 ` SF Markus Elfring
2017-02-13 9:51 ` Johannes Thumshirn [this message]
2017-02-13 10:37 ` SF Markus Elfring
2017-02-13 10:49 ` Johannes Thumshirn
2017-02-10 21:04 ` [PATCH 4/5] IB/hfi1: Use memdup_user() rather than duplicating its implementation in hfi1_user_sdma_process_request() SF Markus Elfring
2017-02-11 15:32 ` Dennis Dalessandro
2017-02-13 9:50 ` [PATCH 27/27] IB/hfi1: Code reuse with memdup_copy SF Markus Elfring
2017-02-13 10:53 ` [PATCH 4/5] IB/hfi1: Use memdup_user() rather than duplicating its implementation in hfi1_user_sdma_process_request() Dan Carpenter
2017-02-13 11:12 ` SF Markus Elfring
2017-02-13 14:01 ` Dan Carpenter
2017-02-10 21:05 ` [PATCH 5/5] IB/hfi1: Improve another size determination " SF Markus Elfring
2017-04-20 20:29 ` [PATCH 0/5] IB/hfi1: Fine-tuning for three function implementations Doug Ledford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ce8c7b1-1ae5-fe15-2740-b4f7653555c4@suse.de \
--to=jthumshirn@suse.de \
--cc=dennis.dalessandro@intel.com \
--cc=dledford@redhat.com \
--cc=elfring@users.sourceforge.net \
--cc=hal.rosenstock@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mike.marciniszyn@intel.com \
--cc=sean.hefty@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).