From: Con Kolivas <kernel@kolivas.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Peter Williams <pwil3058@bigpond.net.au>,
Andrew Morton <akpm@osdl.org>, MIke Galbraith <efault@gmx.de>,
linux-kernel@vger.kernel.org, mingo@elte.hu, "Chen,
Kenneth W" <kenneth.w.chen@intel.com>
Subject: Re: [patch 2.6.16-rc4-mm1] Task Throttling V14
Date: Sat, 25 Feb 2006 13:57:23 +1100 [thread overview]
Message-ID: <200602251357.24665.kernel@kolivas.org> (raw)
In-Reply-To: <43FFC411.8010106@yahoo.com.au>
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
next prev parent reply other threads:[~2006-02-25 2:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 13:45 [patch 2.6.16-rc3-mm1] Task Throttling V9 MIke Galbraith
2006-02-24 20:29 ` [patch 2.6.16-rc4-mm1] Task Throttling V14 MIke Galbraith
2006-02-24 22:15 ` Andrew Morton
2006-02-25 1:16 ` Peter Williams
2006-02-25 2:20 ` MIke Galbraith
2006-02-25 2:42 ` Nick Piggin
2006-02-25 2:57 ` Con Kolivas [this message]
2006-02-25 3:08 ` Nick Piggin
2006-02-25 3:35 ` MIke Galbraith
2006-02-25 2:23 ` MIke Galbraith
2006-03-03 10:43 ` [patch 2.6.16-rc5-mm2] sched_cleanup-V17 - task throttling patch 1 of 2 Mike Galbraith
2006-03-03 10:58 ` [patch 2.6.16-rc5-mm2] sched_throttle-V17 - task throttling patch 2 " Mike Galbraith
2006-03-03 23:58 ` [patch 2.6.16-rc5-mm2] sched_cleanup-V17 - task throttling patch 1 " Peter Williams
2006-03-04 4:54 ` Mike Galbraith
2006-03-04 21:37 ` Peter Williams
2006-03-05 4:53 ` Mike Galbraith
2006-03-05 6:54 ` Mike Galbraith
2006-03-04 2:33 ` Peter Williams
2006-03-04 5:20 ` Mike Galbraith
2006-03-04 5:24 ` Con Kolivas
2006-03-04 5:29 ` Mike Galbraith
2006-03-04 5:40 ` Randy.Dunlap
2006-03-04 5:54 ` Con Kolivas
2006-03-04 6:05 ` Randy.Dunlap
2006-03-04 6:50 ` Mike Galbraith
2006-03-04 6:50 ` Con Kolivas
2006-03-04 7:04 ` Mike Galbraith
2006-03-05 22:29 ` Peter Williams
2006-03-04 21:44 ` Peter Williams
2006-03-04 10:53 ` Mike Galbraith
2006-02-26 11:26 ` [patch 2.6.16-rc4-mm1] Task Throttling V14 Daniel K.
2006-02-26 13:19 ` MIke Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200602251357.24665.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=efault@gmx.de \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pwil3058@bigpond.net.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).