Re: [2.6.16-rc6 patch] remove sleep_avg multiplier

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux