Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()

[Mike Galbraith]

On Wed, 2013-01-23 at 16:30 +0800, Michael Wang wrote: 
> On 01/23/2013 04:20 PM, Mike Galbraith wrote:
> > On Wed, 2013-01-23 at 15:10 +0800, Michael Wang wrote: 
> >> On 01/23/2013 02:28 PM, Mike Galbraith wrote:
> > 
> >>> Abbreviated test run:
> >>> Tasks    jobs/min  jti  jobs/min/task      real       cpu
> >>>   640   158044.01   81       246.9438     24.54    577.66   Wed Jan 23 07:14:33 2013
> >>>  1280    50434.33   39        39.4018    153.80   5737.57   Wed Jan 23 07:17:07 2013
> >>>  2560    47214.07   34        18.4430    328.58  12715.56   Wed Jan 23 07:22:36 2013
> >>
> >> So still not works... and not going to balance path while waking up will
> >> fix it, looks like that's the only choice if no error on balance path
> >> could be found...benchmark wins again, I'm feeling bad...
> >>
> >> I will conclude the info we collected and make a v3 later.
> > 
> > FWIW, I hacked virgin to do full balance if an idle CPU was not found,
> > leaving the preference to wake cache affine intact though, turned on
> > WAKE_BALANCE in all domains, and it did not collapse.  In fact, the high
> > load end, where the idle search will frequently be a waste of cycles,
> > actually improved a bit.  Things that make ya go hmmm.
> 
> Oh, does that means the old balance path is good while the new is really
> broken, I mean, compared this with the previously results, could we say
> that all the collapse was just caused by the change of balance path?

That's a good supposition.  I'll see if it holds.

Next, I'm going to try ripping select_idle_sibling() to tiny shreds,
twiddle the balance path a little to see if I can get rid of the bad
stuff for tbench, maybe make some good stuff for pgbench and ilk, ilk
_maybe_ including heavy duty remote network type loads.

There's gonna be some violent axe swinging here shortly.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/