Re: 2.6.X, NPTL, SCHED_FIFO and JACK

Peter Williams
2004-07-02T01:38:27Z

William Lee Irwin III wrote:
> On Thu, Jul 01, 2004 at 03:45:54PM -0700, Andrew Morton wrote:
>
>>In fairness, the CPU scheduler has been spinning like a top for a
>>couple of years, and it still ain't settled.
>>That's just the one in Linus's tree, let alone the umpteen rewrites
>>which are floating about.
>
>
> I've not seen much deep material there. Policy tweaks seem to be
> what's gone on in mainline, and frankly most of the purported rewrites
> are just that. I guess the ones that nuked the duelling queue silliness
> are trying qualify but even they're leaving the load balancer untouched
> and are carrying over large fractions of their predecessors unaltered.

That's because it's not all bad (or the problems are minor and can wait
until later).

> The stuff that's gone around looks minor. It's not like they're teaching
> sched.c to play cpu tetris for gang scheduling or Kalman filtering
> profiling feedback to stripe tasks using different cpu resources across
> SMT siblings or playing graph games to meet RT deadlines, so it doesn't
> look like very much at all is going on to me.

To my mind, scheduling and load balancing are ALMOST orthogonal
concepts. Scheduling is concerned with doing a useful job within a
single CPU and load balancing is about distributing tasks/load among the
available CPUs. To a large extent these are independent and are being
worked on separately. I am one of those fiddling with the schedulers
but I'm leaving load balancing alone as it seems to me that the NUMA and
hyper threading developers are the main players for that component.

To my mind the only contribution the scheduler component MAY want to
make to load balancing would be to have some say in which tasks are
chosen for migration. I don't think that any of the currently proposed
schedulers have a strong need to change the current mechanism(s) for
selecting which tasks get migrated. If you think otherwise please share
your thoughts?

>
> It's pretty obvious why everyone and their brother is grinding out
> purported scheduler rewrites: the code is self-contained,

The main reason is that the standard scheduler is a bit of a mess. The
fact that the code is self contained just makes it easier to modify
without touching lots of files. It's not the reason why the changes are
being tried.

> however,
> nothing interesting is coming of all this. Never been for have so many
> patches been written against the same file, accomplishing so little.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce