On 01/23/2013 04:49 PM, Mike Galbraith wrote: > 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.
I just notice that there is no sd support the WAKE flag at all according to your debug info, isn't it? Which means there is no way to do load balance since we can even not found a suitable sd for wake up...totally confusing me now ;( Regards, Michael Wang > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
