lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4CFD59CD0200005A00077F6C@novprvoes0310.provo.novell.com>
Date:	Mon, 06 Dec 2010 19:46:53 -0700
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>,
	<linux-kernel@...r.kernel.org>
Cc:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH 04/10] sched: Change pick_next_task_rt from
 unlikely to likely

>>> On 12/6/2010 at 08:58 PM, in message <20101207021329.185936860@...dmis.org>,
Steven Rostedt <rostedt@...dmis.org> wrote: 
> From: Steven Rostedt <srostedt@...hat.com>
> 
> The if (unlikely(!rt_rq->rt_nr_running)) test in pick_next_task_rt()
> tests if there is another rt task ready to run. If so, then pick it.
> 
> In most systems, only one RT task runs at a time most of the time.
> Running the branch unlikely annotator profiler on a system doing average
> work "running firefox, evolution, xchat, distcc builds, etc", it showed the
> following:

My feeling is that generally speaking, if the branch is workload dependent, we should probably not annotate it at all and let the CPUs branch-predictor do its thing.  I guess what I am not 100% clear on is how these annotations affect the BPU.  I.e. is it a static decision point or can the BPU still "learn" if the annotation is particularly wrong for a given workload?  For the former, I think we should just remove this particular annotation (and there are others that need review).  For the latter, this is obviously the right annotation we should be using in this particular case.

-Greg

> 
>  correct incorrect  %        Function                  File              
> Line
>  ------- ---------  -        --------                  ----              ----
>   324344 135104992  99 _pick_next_task_rt             sched_rt.c           
> 1064
> 
> 99% of the time the condition is true. When an RT task schedules out,
> it is unlikely that another RT task is waiting to run on that same run 
> queue.
> 
> Cc:Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Cc: Gregory Haskins <ghaskins@...ell.com>
> Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
> ---
>  kernel/sched_rt.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> index 7a5c4db..a249ae3 100644
> --- a/kernel/sched_rt.c
> +++ b/kernel/sched_rt.c
> @@ -1062,7 +1062,7 @@ static struct task_struct *_pick_next_task_rt(struct rq 
> *rq)
>  
>  	rt_rq = &rq->rt;
>  
> -	if (unlikely(!rt_rq->rt_nr_running))
> +	if (likely(!rt_rq->rt_nr_running))
>  		return NULL;
>  
>  	if (rt_rq_throttled(rt_rq))




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ