From: Con Kolivas <kernel@kolivas.org>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Peter Williams <pwil3058@bigpond.net.au>,
mingo@elte.hu, nickpiggin@yahoo.com.au,
linux-kernel@vger.kernel.org
Subject: Re: smp 'nice' bias support breaks scheduler behavior
Date: Fri, 27 Jan 2006 13:58:52 +1100 [thread overview]
Message-ID: <200601271358.52501.kernel@kolivas.org> (raw)
In-Reply-To: <20060126181118.C19789@unix-os.sc.intel.com>
On Friday 27 January 2006 13:11, Siddha, Suresh B wrote:
> On Fri, Jan 27, 2006 at 12:54:53PM +1100, Con Kolivas wrote:
> > It's not my decision to keep Peter's patch out of mainline. If you can
> > make a strong enough case for it then Linus will merge it up even though
> > it's after rc1.
>
> I don't want to push Peters patch to 2.6.16, as I haven't tested much.
>
> > Otherwise I'll let Ingo decide on whether to pull the current
> > implementation or not - you're saying that with the one thing you
> > described that misbehaves that it is doing more harm than fixing smp nice
> > handling.
>
> Are we sure that it really fixes smp nice handling? Its not just one
> scenario(bouncing processes on a lightly loaded system), I am talking
> about. Imbalance calculations will be wrong even on a completely loaded
> system.. Are you sure that there are no perf regressions with your patch..
It was extensively tested for more than 3 months in the -mm tree. Early on
there were accounting bugs in the code which I corrected and we saw no
performance regression after that across a wide range of benchmarks and
hardware configurations at the time thanks to M Bligh. (see test.kernel.org)
Some were done on the osdl (STP) test bench showing no regression as well but
the osdl infrastructure became pretty much unworkable not long after.
> Sorry for commenting on this patch so late.. I was on a very long vacation.
> I think it is safe to back that out for 2.6.16 and do more work and get it
> in 2.6.17.
Well I have no emotional investment in the code, I just want to do what's
right. In the absence of measurable throughput regressions and improvement in
smp nice handling I don't believe we should back it out.
Cheers,
Con
prev parent reply other threads:[~2006-01-27 2:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-26 10:52 smp 'nice' bias support breaks scheduler behavior Siddha, Suresh B
2006-01-26 12:25 ` Con Kolivas
2006-01-26 23:36 ` Peter Williams
2006-01-26 23:56 ` Siddha, Suresh B
2006-01-27 1:29 ` Con Kolivas
2006-01-27 1:34 ` Siddha, Suresh B
2006-01-27 1:54 ` Con Kolivas
2006-01-27 2:11 ` Siddha, Suresh B
2006-01-27 2:58 ` Con Kolivas [this message]
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=200601271358.52501.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pwil3058@bigpond.net.au \
--cc=suresh.b.siddha@intel.com \
/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