From: Con Kolivas <kernel@kolivas.org>
To: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [2.6.16-rc6 patch] remove sleep_avg multiplier
Date: Tue, 14 Mar 2006 23:29:30 +1100 [thread overview]
Message-ID: <200603142329.31281.kernel@kolivas.org> (raw)
In-Reply-To: <1142339099.11303.12.camel@homer>
On Tuesday 14 March 2006 23:24, Mike Galbraith wrote:
> On Tue, 2006-03-14 at 23:07 +1100, Con Kolivas wrote:
> > On Tuesday 14 March 2006 22:56, Mike Galbraith wrote:
> > > With my full change set, you _will_ see differences with interbench.
> > > Interbench will say you're better off without my changes in fact. Run
> > > any of the known scheduler exploits without my changes, and then with,
> > > and you'll likely consider revising interbench a little methinks ;-)
> >
> > Not really; interbench is after interactivity, and exploit prone designs
> > don't necessarily have bad interactivity. If you can reproduce the nfs
> > case as an extra load for interbench I'd love to include it.
>
> Yes, interbench tries to assess interactivity, but it gets it totally
> wrong sometimes. It runs it's measurement at a high priority, and calls
> the result good if it was able to get as much cpu as it wants.
You misunderstand the code and/or my intent. There is a thread at high
priority that does timing and signalling only, but the loads and benchmarked
simulations are run at normal priority (nice 0) or at a nice level set by
yourself in the options.
> The very
> code responsible for good interbench numbers is also responsible for
> starvation problems. It's the long sleep logic. That logic makes my
> box suck rocks under thud and irman2.
>
> Don't forget, every one of the exploits I test with were posted by
> people who were experiencing scheduler problems in real life. Try to
> use your box while running those exploits, and then tell me that you
> agree with interbench's assessment.
Ok you feel interbench is an irrelevant benchmark for your test case and I'm
not going to bother arguing since it doesn't claim to test every single
situation.
That doesn't change the fact that your patch has only been tested by yourself.
Don't forget I'm still agreeing with your change, I'm just suggesting the
usual patch precautions.
Cheers,
Con
next prev parent reply other threads:[~2006-03-14 12:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-14 9:51 [2.6.16-rc6 patch] remove sleep_avg multiplier Mike Galbraith
2006-03-14 9:56 ` Ingo Molnar
2006-03-14 10:05 ` Con Kolivas
2006-03-14 10:10 ` Con Kolivas
2006-03-14 11:56 ` Mike Galbraith
2006-03-14 12:07 ` Con Kolivas
2006-03-14 12:24 ` Mike Galbraith
2006-03-14 12:29 ` Con Kolivas [this message]
2006-03-14 12:36 ` Con Kolivas
2006-03-14 12:40 ` Mike Galbraith
2006-03-14 12:47 ` Con Kolivas
2006-03-14 12:59 ` 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=200603142329.31281.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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