linux-kernel - Re: [PATCH 11/18] swim: dequeue in-flight request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 17 May 2009 07:18:18 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
CC:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-ide@...r.kernel.org, rusty@...tcorp.com.au,
	James.Bottomley@...senPartnership.com, mike.miller@...com,
	donari75@...il.com, paul.clements@...eleye.com, tim@...erelk.net,
	Geert.Uytterhoeven@...ycom.com, davem@...emloft.net,
	Laurent@...vier.info, jgarzik@...ox.com, jeremy@...source.com,
	grant.likely@...retlab.ca, adrian@...en.demon.co.uk,
	sfr@...b.auug.org.au, bzolnier@...il.com, petkovbb@...glemail.com,
	oakad@...oo.com, drzeus@...eus.cx, dwmw2@...radead.org,
	Markus.Lidel@...dowconnect.com, wein@...ibm.com,
	schwidefsky@...ibm.com, zaitcev@...hat.com,
	fujita.tomonori@....ntt.co.jp, axboe@...nel.dk
Subject: Re: [PATCH 11/18] swim: dequeue in-flight request

Hello, Sergei.

Sergei Shtylyov wrote:
>> Similar response as the if/else one on the other thread.  Is it really
>> any significantly better?  The 'duplication' here is basically one
>> liner
> 
>   Not true, it's 3-liner. I wouldn't bother with one liner.

The final result is...

	req = blk_fetch_request(q);
	while (req) {
		int err = -EIO;

That looks like one liner to me.

>> after the peek/fetch change
> 
>   The peek/fetch code itself is duplicated. :-/

Do you mean by inlining?  Please note that blk_fetch_request() is not
inlined anymore after Fujita's bidi end_request cleanup patches.

>> and when the duplication is minimal,
>> I usually find it clearer to put the loop condition at the while
>> clause itself.
> 
>   No problem, we could just keep an old form of *while* loop.
> 
>> If you think it's significantly better,
> 
>   I do hink it avoids duplicating peek/fetch code.
> 
>> please go ahead and submit the patch but to me the change you're
>> proposing is
>> basically cosmetic and not even a clearly better one at that.
> 
> Should probably look at the resulting assembly to see how much it's
> differrent.

Do you seriously think it's worthwhile to optimize the request loop
according to assembly generation?  That sounds like a bad case of over
(micro) optimization to me.  It's not gonna make any noticeable
difference and the changes you make today can be irrelevant or even
deterimental tomorrow depending on any number of parameters.  Please
don't do it for performance reasons.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/