Re: 2.6.X, NPTL, SCHED_FIFO and JACK

[William Lee Irwin III]

William Lee Irwin III wrote:
>> 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.

On Fri, Jul 02, 2004 at 11:38:17AM +1000, Peter Williams wrote:
> That's because it's not all bad (or the problems are minor and can wait 
> until later).

Whatever that has to do with, it doesn't really make the fiddling around
going on even noticeable. Hell, I do end-luserish crap too (amazing, I
actually appear to need luserspace to get code written) I've yet to see
a visible change in scheduler behavior in that context across all of
2.4 and 2.5 (and in fact since the earliest Linux kernels I've ever run)
apart from a reduction in cpu time spent in the scheduler itself
associated with (you guessed it) the merge of the incremental epoch
expiry stuff mingo did around early 2.5 (or at least that's the best
description I can come up with the algorithm, as it doesn't resemble any
of the normal algorithms). I suspect widespread placebo effects.


William Lee Irwin III wrote:
>> 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.

On Fri, Jul 02, 2004 at 11:38:17AM +1000, Peter Williams wrote:
> 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?

That's an expedient program structure. There is no independence. Those
are examples of things that would have qualified as having been remotely
visible changes and not myriads of infinitesimal intra-queue twiddlings.

No, I don't want to touch scheduling policy (or anything else infested
with such massive quantities of holy penguin pee) with a 10-foot pole.


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

On Fri, Jul 02, 2004 at 11:38:17AM +1000, Peter Williams wrote:
> 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.

It means the barrier to entry is very low.


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

s/been for/before/

I wonder why I've started making homophone errors only in the past 5 years
where beforehand they were very rare. It's not like I started sounding out
words when I read or anything idiotic like that.


-- wli
-
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/