unlikely compiler flag propagation
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? Thanks a lot, Matthias -- motzblog.wordpress.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. thanks, greg k-h
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
On Wed, Feb 18, 2015 at 07:35:37PM +0100, Matthias Brugger wrote:
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?
There is no "propagation" of a likely/unlikely mark as it is just a hint for that specific comparison test. thanks, greg k-h
On Wed, 18 Feb 2015, Greg KH wrote:
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.
interesting - would you have a reference to some talk/paper/data/... ?
So just don't use it, unless you can measure it.
thx! hofrat
On Wed, 18 Feb 2015 19:38:01 +0100, Nicholas Mc Guire said:
On Wed, 18 Feb 2015, Greg KH wrote:
interesting - would you have a reference to some talk/paper/data/... ?
Test for yourself :) config PROFILE_ANNOTATED_BRANCHES bool "Trace likely/unlikely profiler" select TRACE_BRANCH_PROFILING help This tracer profiles all likely and unlikely macros in the kernel. It will display the results in: /sys/kernel/debug/tracing/trace_stat/branch_annotated Note: this will add a significant overhead; only turn this on if you need to profile the system's use of these macros.
On Wed, 18 Feb 2015, Valdis.Kletnieks@vt.edu wrote:
On Wed, 18 Feb 2015 19:38:01 +0100, Nicholas Mc Guire said:
On Wed, 18 Feb 2015, Greg KH wrote:
interesting - would you have a reference to some talk/paper/data/... ?
Test for yourself :)
config PROFILE_ANNOTATED_BRANCHES bool "Trace likely/unlikely profiler" select TRACE_BRANCH_PROFILING help This tracer profiles all likely and unlikely macros in the kernel. It will display the results in:
/sys/kernel/debug/tracing/trace_stat/branch_annotated
Note: this will add a significant overhead; only turn this on if you need to profile the system's use of these macros.
was not aware of that - many thanks ! I do assume that such a claim of 90% not being effective would not be based on testing some single system but based on a much wider basis so that data would be interesting to see data from different clases of systems. thx! hofrat
[2015-02-19T00:08:01+0530]: "Nicholas Mc Guire" (nicholas-mcguire): nicholas-mcguire> On Wed, 18 Feb 2015, Greg KH wrote: ,----[ greg-kh ] | 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. `----
,----[ nicholas-mcguire ] | interesting - would you have a reference to some talk/paper/data/... ? `---- couple of 'slightly' oldish posts: http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html and http://thread.gmane.org/gmane.linux.kernel/1072767 --- thanks anupam
participants (5)
-
Anupam Kapoor -
Greg KH -
Matthias Brugger -
Nicholas Mc Guire -
Valdis.Kletnieks＠vt.edu