linux-kernel - Re: [PATCH] libata-sff: fix 32-bit PIO regression

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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 08 Feb 2009 19:19:07 -0500
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
CC:	Mikael Pettersson <mikpe@...uu.se>,
	Hugh Dickins <hugh@...itas.com>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk, rjw@...k.pl
Subject: Re: [PATCH] libata-sff: fix 32-bit PIO regression

Sergei Shtylyov wrote:
>   Do you really think that the transfers having lengths non-divisible by 
> 4 make any *significant* percentage even on the ATAPI devices? I think 
> it's you who is really wrong.

The answer depends on workload.  Though rare, workloads do exist that 
involve a lot of oddball querying via weird, vendor-specific SCSI[-ish] 
commands.

Moreover, the likelihood and cost of a branch mispredict are both low in 
this case, IMO.

Or a more human version of the rule:  if you have to have a long email 
thread about unlikely() placement, it is best just to avoid using 
unlikely() in that case at all.  Branch prediction units in modern CPUs 
are damned good anyways, and there is always the likelihood that a 
human-placed unlikely() becomes wrong in the future.

Plus the code is more readable without unlikely(), IMO.

	Jeff

--
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/