unlikely compiler flag propagation

unlikely compiler flag propagation

[Matthias Brugger]

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

unlikely compiler flag propagation

[Greg KH]

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

unlikely compiler flag propagation

[Matthias Brugger]

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/page_alloc.c#n2171
[1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/mm/page_alloc.c#n966

>
> thanks,
>
> greg k-h



-- 
motzblog.wordpress.com

unlikely compiler flag propagation

[Nicholas Mc Guire]

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 

unlikely compiler flag propagation

[Valdis.Kletnieks at vt.edu]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150218/737f971a/attachment.bin 

unlikely compiler flag propagation

[Nicholas Mc Guire]

On Wed, 18 Feb 2015, Valdis.Kletnieks at 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

unlikely compiler flag propagation

[Greg KH]

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

unlikely compiler flag propagation

[Anupam Kapoor]

>>>>> [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