Hi Greg, hi all, 2015-02-18 19:24 GMT+01:00 Greg KH <greg@kroah.com>:
On Wed, Feb 18, 2015 at 07:09:47PM +0100, Matthias Brugger wrote:
Hi all,
I have a question about the unlikely compiler flag. When a called function is only returns an error with the unlikely flag set, should I set the unlikely compiler flag for the return value check in the callee as well?
For example:
int function_one(int *list, int num_elements) { int i; for (i =0; i < num_elements; i++) { if (unlikely(check_element(list + i))) return 1; }
[...]
return 0; }
int function_two(...) { [...]
if (function_one(list, num)) return -1; }
So my question is, if function_two should instead implement: if (unlikely(function_one(list, num))
Or does the unlikely compiler flag propagate to calling functions?
NEVER use unlikely/likely unless you can actually measure that it matters if you use it. The compiler and processor is almost always better at making these types of guesses and predictions, so let it do the work instead.
As proof of this, there was a test of the kernel a year or so ago that measured the placement of the existing likely/unlikely markers in the kernel and 90% of the usages were wrong and actually slowed down the processor.
So just don't use it, unless you can measure it.
I was just asking about the propagation because I found that get_page_from_freelist [0] in mm/page_alloc.c calls prep_new_page [1] which in place returns an error when entering an unlikely marked branch. As this happens in the fast path of a page allocation, I hope the marker is properly set :) So is it needed to set the unlikely in the get_page_from_freelist as well, or will the compiler propagate the mark? Cheers, Matthias [0] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/mm/pag... [1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/mm/pag...
thanks,
greg k-h
-- motzblog.wordpress.com