[lkml]   [2008]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [tbench regression fixes]: digging out smelly deadmen.
On Tue, 2008-10-28 at 11:37 +0100, Ingo Molnar wrote:
> * Mike Galbraith <> wrote:
> > ..removing the overhead from .27 does not produce the anticipated
> > result despite a max context switch rate markedly above that of
> > 2.6.26.
> >
> > There lies an as yet unaddressed regression IMBHO. The hrtick has
> > been addressed. It sucked at high frequency, and it's gone. The
> > added math overhead in .27 hurt some too, and is now history as
> > well.
> thanks Mike for the _extensive_ testing and bug hunting session you've
> done in the past couple of weeks! All the relevant fixlets you found
> are now queued up properly in sched/urgent, correct?


> What's your gut feeling, is that remaining small regression scheduler
> or networking related?

I don't know where it lives. I'm still looking, and the numbers are
still playing games with my head.

> i'm cutting the ball in half and i'm passing over one half of it to
> the networking folks, because your numbers show _huge_ sensitivity in
> this workload, depending on networking settings:

I strongly _suspect_ that the network folks have some things they could
investigate, but given my utter failure at finding the smoking gun, I
can't say one way of the other. IMHO, sharing with network folks would
likely turn out to be a fair thing to do.

Am I waffling? Me? You bet your a$$! My clock is already squeaky clean
thank you very much :-)

What I can say is that my box is quite certain that there are influences
outside the scheduler which have more influence benchmark results than
the scheduler does through the life of testing.


 \ /
  Last update: 2008-10-28 12:01    [W:0.113 / U:20.464 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site