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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.