Investigate possibility of using unlikely(), likely()

[Martin Decky]

Use the constructs unused(), unlikely() and likely() in relevant parts of the code.

[Jiri Svoboda]

I am strongly against this. You are basically trying to hand-optimize the code for speed. If you can actually attain some noticeable speed improvement by putting this in a few extremely hot spots, then maybe. Otherwise you are just obfuscating the code. Moreover, in many times your guess about what's 'likely' can be utterly wrong.

[Jiri Svoboda]

I am closing this ticket as it does not really describe an improvement. If you are concerned with the performance of the kernel, then I suggest you log a ticket for that. Analyzing/profiling the hot paths and finding a way to improve performance (noticeably) is a good ticket assignment. Suggesting to obfuscate the code for no provable benefit is not.

[Jiri Svoboda]

OK, maybe I don't have to close this ticket, but let me rephrase this. We are talking about hand-optimization. Hand-optimization should always be used as a last resort — avoid them as much as possible. What we can do:

• Profile the kernel and determine the hottest functions/paths
• Identify if() statements on these hottest paths
• Try placing likely()/unlikely() in appropriate places and measure the performance benefit.
• For individual uses of likely()/unlikely() which bring considerable performance improvement, consider integrating them.
• Any use of likely()/unlikely() that cannot be supported by both logical explanation and measurement should be avoided.

Another note: What is the unused() macro? If it is meant to be some way of annotating unused variables, it might be a good idea, but completely unrelated. Please open a separate ticket for discussion thereof.

[Jakub Jermář]

The need for this has been very low in the last 10 years. Closing now.