Hello.
Jeff Garzik 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.
Can you give an example of a *continous* querying with the data
transferring commands?
Hm, it just occured to me that the typical ATAPI command packet is 12
bytes long.
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.
There are still CPUs without the branch prediction, you know -- Linux
runs not only on x86.
Plus the code is more readable without unlikely(), IMO.
I tend to disagree. However, the packet command transfer is not
unlikely at all, so I'll remove that unlikely() in the respun patch.
Jeff
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
