Re: [patch 2.6.16-rc4-mm1] Task Throttling V14

[Con Kolivas <kernel@kolivas.org>]

On Saturday 25 February 2006 13:42, Nick Piggin wrote:
> Peter Williams wrote:
> > Andrew Morton wrote:
> >> MIke Galbraith <efault@gmx.de> wrote:
> >>> Not many comments came back, zero actually.
> >>
> >> That's because everyone's terribly busy chasing down those final bugs
> >> so we
> >> get a really great 2.6.16 release (heh, I kill me).
> >>
> >> I'm a bit reluctant to add changes like this until we get the smpnice
> >> stuff
> >> settled down and validated.  I guess that means once Ken's run all his
> >> performance tests across it.
> >>
> >> Of course, if Ken does his testing with just mainline+smpnice then any
> >> coupling becomes less of a problem.  But I would like to see some
> >> feedback
> >> from the other sched developers first.
> >
> > Personally, I'd rather see PlugSched merged in and this patch be used to
> > create a new scheduler inside PlugSched.  But I'm biased :-)
> >
> > As I see it, the problem that this patch is addressing is caused by the
> > fact that the current scheduler is overly complicated.  This patch just
> > makes it more complicated.  Some of the schedulers in PlugSched already
> > handle this problem adequately and some of them are simpler than the
> > current scheduler -- the intersection of these two sets is not empty.
> >
> > So now that it's been acknowledged that the current scheduler has
> > problems, I think that we should be looking at other solutions in
> > addition to just making the current one more complicated.
>
> I tried this angle years ago and it didn't work :)

Our "2.6 forever" policy is why we're stuck with this approach. We tried 
alternative implementations in -mm for a while but like all alternatives they 
need truckloads more testing to see if they provide a real advantage and 
don't cause any regressions. This made it impossible to seriously consider 
any alternatives.

I hacked on and pushed plugsched in an attempt to make it possible to work on 
an alternative implementation that would make the transition possible in a 
stable series. This was vetoed by Linus and Ingo and yourself for the reason 
it dilutes developer effort on the current scheduler. Which leaves us with 
only continually polishing what is already in place.

None of this is news of course but it helps to set the history for outside 
observers of this thread.

Cheers,
Con
-
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/