Re: [CFT][RFC] HT scheduler

[Nick Piggin]

Rusty Russell wrote:

> In message <3FDAB517.4000309@xxxxxxxxxxxxxxx> you write:
>
> > Rusty Russell wrote:
> >
> >
> > > In message <3FD9679A.1020404@xxxxxxxxxxxxxxx> you write:
> > >
> > >
> > > > Thanks for having a look Rusty. I'll try to convince you :)
>
> Actually, having produced the patch, I've changed my mind.
>
> While it was spiritually rewarding to separate "struct runqueue" into
> the stuff which was to do with the runqueue, and the stuff which was
> per-cpu but there because it was convenient, I'm not sure the churn is
> worthwhile since we will want the rest of your stuff anyway.

OK nice, I haven't heard any other objections. I'll be trying to get
this included in 2.6, so if anyone doesn't like it please speak up.

> It (and lots of other things) might become worthwhile if single
> processors with HT become the de-facto standard.  For these, lots of
> our assumptions about CONFIG_SMP, such as the desirability of per-cpu
> data, become bogus.
>
> A few things need work:
>
> 1) There's a race between sys_sched_setaffinity() and
>   sched_migrate_task() (this is nothing to do with your patch).

Yep. They should both take the task's runqueue lock.

> 2) Please change those #defines into an enum for idle (patch follows,
>   untested but trivial)

Thanks, I'll take the patch.

> 3) conditional locking in load_balance is v. bad idea.

Yeah... I'm thinking about this. I don't think it should be too hard
to break out the shared portion.

> 4) load_balance returns "(!failed && !balanced)", but callers stop
>   calling it when it returns true.  Why not simply return "balanced",
>   or at least "balanced && !failed"?

No, the idle balancer stops calling it when it returns true, the periodic
balancer sets idle to 0 when it returns true.

!balanced && !failed means it has moved a task.

I'll either comment that, or return it in a more direct way.


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