On Sat, 17 Nov 2007, Gregory Haskins wrote:
> >>> On Sat, Nov 17, 2007 at 1:21 AM, in message
> <[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> > Gregory Haskins RT balancing broke sched domains.
>
> Doh! (though you mean s/domains/stats ;)
Heh, indeed.
>
> > This is a fix to allow it to still work.
> >
> > Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> >
> > ---
> > include/linux/sched.h | 3 ++-
> > kernel/sched.c | 17 ++++++++++++++---
> > kernel/sched_fair.c | 19 ++++++++++++++-----
> > kernel/sched_idletask.c | 3 ++-
> > kernel/sched_rt.c | 3 ++-
> > 5 files changed, 34 insertions(+), 11 deletions(-)
> >
> > Index: linux-compile.git/kernel/sched.c
> > ===================================================================
> > --- linux-compile.git.orig/kernel/sched.c 2007-11-17 00:15:57.000000000
> > -0500
> > +++ linux-compile.git/kernel/sched.c 2007-11-17 00:15:57.000000000
> > -0500
> > @@ -1453,6 +1453,7 @@ static int try_to_wake_up(struct task_st
> > unsigned long flags;
> > long old_state;
> > struct rq *rq;
> > + struct sched_domain *this_sd = NULL;
> > #ifdef CONFIG_SMP
> > int new_cpu;
> > #endif
> > @@ -1476,10 +1477,20 @@ static int try_to_wake_up(struct task_st
> > schedstat_inc(rq, ttwu_count);
> > if (cpu == this_cpu)
> > schedstat_inc(rq, ttwu_local);
> > - else
> > - schedstat_inc(rq->sd, ttwu_wake_remote);
> > + else {
> > +#ifdef CONFIG_SCHEDSTATS
> > + struct sched_domain *sd;
> > + for_each_domain(this_cpu, sd) {
> > + if (cpu_isset(cpu, sd->span)) {
> > + schedstat_inc(sd, ttwu_wake_remote);
> > + this_sd = sd;
> > + break;
> > + }
> > + }
> > +#endif /* CONFIG_SCHEDSTATES */
> > + }
> >
> > - new_cpu = p->sched_class->select_task_rq(p, sync);
> > + new_cpu = p->sched_class->select_task_rq(p, this_sd, sync);
>
> I like this optimization, but I am thinking that the location of the stat
> update is now no longer relevant. It should potentially go *after* the
> select_task_rq() so that we pick the sched_domain of the actual wake target,
> not the historical affinity. If that is accurate, I'm sure you can finagle
> this optimization to work in that scenario too, but it will take a little
> re-work.
Yeah, I can take a deep look. This was written late at night, so I need to
spend more "awake" hours on it.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
