Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 18 May 2007 17:54:32 -0400
Phillip Susi <[email protected]> wrote:
But as Jeff said, that's not what unlikely is for. It should only be
used when it is unlikely for everybody, all the time, because when it
is right, it helps rather little, but when it is wrong, it hurts a lot.
It does? Tell us more.
It is difficult to quantify either way. The details are both
CPU-specific and compiler-specific. The best information can be culled
from the gcc list archives, which is where I obtained my knowledge on
the subject (which is now ~2 years old).
Under the hood, likely() and unlikely() are implemented as percentage
predictions. likely() is implemented in the kernel as a 99-100% chance
of success, and unlikely() is implemented as a 0-1% chance of success.
As such, for our purposes, likely() and unlikely() should only be used
when a situation is [likely | unlikely] across all runtime
configurations. So if you mark a branch unlikely() when it is hit often
by 1% of your users, that is an incorrect usage.
The effects are probably most dramatic on older CPUs. Repeatedly
hitting an unlikely() can cause a pipeline stall on every single access.
Branch delay slots are filled improperly, with obvious implications.
But on modern hardware, I would /guess/ that the effect of repeatedly
hitting an unlikely() would be mitigated by smarter branch prediction.
We really need a GCC expert to answer this question in any more detail.
Aside from using branch constructs or hints that help the predictor
guess the right way... I think gcc will move unlikely paths right past
the end of the "likely" fastpath, so it can increase code size and be
somewhat suboptimal in terms of icache usage.
I don't know particularly why it would hurt a lot more when it goes
wrong than it helps when it goes right, though.
Also, I don't think I agree that it should be used where it is correct
for all users. We make rt_task unlikely in the scheduler, and I measured
that a very long time ago was IIRC good for nearly 5% pipe based context
switching peformance. Systems running a lot of rt tasks aren't going to
like it, but bugger them :)
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
