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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, I wrote:

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

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.

  Haha, I even can't count! 12 divides by 4, of course. :-D

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. Moreover, the likelihood and cost of a branch mispredict are both low in this case, IMO.

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.

  No, I'll keep it now. This case is indeed unlikely.

    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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux