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
| ||
|
Date: Mon, 06 Dec 2010 21:59:28 -0500 From: Steven Rostedt <rostedt@...dmis.org> To: Gregory Haskins <ghaskins@...ell.com> Cc: linux-kernel@...r.kernel.org, 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 Mon, 2010-12-06 at 19:46 -0700, Gregory Haskins wrote: > >>> 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. I'm fine with just removing the likely() here. It is a bit workload dependent. We can't assume that we are running a lot of RT tasks on a single CPU, but we also should not assume that we are not doing so. Considering that we are just coming out of an RT task, I doubt it will hurt anything to just keep the annotation off. I don't think gcc does anything special for x86 with regards to the BPU. But I do believe that gcc will add special ops for likely()'s on other archs. -- Steve -- 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