--
On Fri, 26 Oct 2007, Gregory Haskins wrote:

quoted text
> On Fri, 2007-10-26 at 10:47 -0400, Steven Rostedt wrote:
> > --
> > On Fri, 26 Oct 2007, Gregory Haskins wrote:
> >
> > > This version has the feedback from Steve's review incorporated
> > >
> > > -----------------------------------------
> > >
> > > RT: Cache cpus_allowed weight for optimizing migration
> > >
> > > Some RT tasks (particularly kthreads) are bound to one specific CPU.
> > > It is fairly common for one or more bound tasks to get queued up at the
> > > same time.  Consider, for instance, softirq_timer and softirq_sched.  A
> > > timer goes off in an ISR which schedules softirq_thread to run at RT50.
> > > Then during the handling of the timer, the system determines that it's
> > > time to smp-rebalance the system so it schedules softirq_sched to run
> > > from within the softirq_timer kthread context. So we are in a situation
> > > where we have two RT50 tasks queued, and the system will go into
> > > rt-overload condition to request other CPUs for help.
> > >
> > > The problem is that these tasks cannot ever be pulled away since they
> > > are already running on their one and only valid RQ.  However, the other
> > > CPUs cannot determine that the tasks are unpullable without going
> > > through expensive checks/locking.  Therefore the helping CPUS
> >
> > A little exageration there ;-)  We don't need to go through locking (at
> > least my code doesn't), and the checks are not that expensive (could cause
> > some unneeded cache bouncing though).
>
> Well, its all relative.  Not going into overload to begin with, and
> therefore not hitting the pull_rt_tasks() logic outright should be
> faster than lockless scanning tricks ;)
>
> But I digress.  I don't think the original code had your optimization,
> so you are right:  It's perhaps a bit of an exaggeration in HEAD.  I'll
> be less dramatic for the next drop ;)
>

I'll digress some more ;-)

Actually, what I want to stress is that the greatest benefit of this patch
is not removing the unneed checks to processes that can't migrate (it is a
benefit though), but the real benefit that I'm looking forward to is the
migrating of lower priority tasks that can migrate. And these tasks wont
be affected by tasks that can't migrate.

Looking forward to your next patch.

-- Steve

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