linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"target-devel@vger.kernel.org" <target-devel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] target/file: don't zero iter before iov_iter_bvec
Date: Mon, 11 Jan 2021 02:28:52 +0000	[thread overview]
Message-ID: <68887abc-2ef4-035e-625b-84569c1b5b24@gmail.com> (raw)
In-Reply-To: <BYAPR04MB4965E008861D5B29B9E757D186AB0@BYAPR04MB4965.namprd04.prod.outlook.com>

On 11/01/2021 02:06, Chaitanya Kulkarni wrote:
> On 1/9/21 13:29, Pavel Begunkov wrote:
>> On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
>>> On 1/9/21 12:40, Pavel Begunkov wrote:
>>>> I expect you won't find any, but such little things can pile up
>>>> into a not-easy-to-spot overhead over time.
>>> That is what I suspected with the resulting assembly. The commit log
>>> needs to document that there is no direct impact on the performance
>> It's obvious that 3-4 extra mov $0 off(%reg) won't change performance
>> but still hasn't been formally confirmed ...
> This is obvious for you and me since we spent time into looking into
> resulting assembly not every reviewer is expected to do that see [1].
>>
>>> which can be seen with this patch, but this is nice to have
>> ... so if you don't mind, I won't be resending just for that.
> As per commit log guidelines [1] you have to quantify the optimization.
> 
> Since you cannot quantify the optimization modify the commit log explaining

And then you see "Optimizations usually aren’t free but trade-offs
between", and the patch doesn't fall under it.

Let me be frank, I see it more like as a whim. If the maintainer agrees
with that strange requirement of yours and want to bury it under
bureaucracy, fine by me, don't take it, I don't care, but I haven't
ever been asked here to do that for patches as this.

> that there is not significant performance benefit observe.

It's not "I cannot" but rather "I haven't even tried to and expect...".
Don't mix, there is a huge difference between.

-- 
Pavel Begunkov

  reply	other threads:[~2021-01-11  2:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-09 15:53 [PATCH] target/file: don't zero iter before iov_iter_bvec Pavel Begunkov
2021-01-09 20:09 ` Chaitanya Kulkarni
2021-01-09 20:37   ` Pavel Begunkov
2021-01-09 20:52     ` Chaitanya Kulkarni
2021-01-09 21:25       ` Pavel Begunkov
2021-01-11  2:06         ` Chaitanya Kulkarni
2021-01-11  2:28           ` Pavel Begunkov [this message]
2021-01-11  5:23             ` Chaitanya Kulkarni
2021-01-11  5:31               ` Pavel Begunkov
2021-01-11  2:49 ` Bart Van Assche
2021-01-13  5:34 ` Martin K. Petersen
2021-01-15  4:08 ` Martin K. Petersen

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=68887abc-2ef4-035e-625b-84569c1b5b24@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=target-devel@vger.kernel.org \
    /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).