On Mon, 2013-01-28 at 12:29 +0100, Borislav Petkov wrote: > On Mon, Jan 28, 2013 at 11:44:44AM +0100, Mike Galbraith wrote: > > On Mon, 2013-01-28 at 10:55 +0100, Borislav Petkov wrote: > > > On Mon, Jan 28, 2013 at 06:17:46AM +0100, Mike Galbraith wrote: > > > > Zzzt. Wish I could turn turbo thingy off. > > > > > > Try setting /sys/devices/system/cpu/cpufreq/boost to 0. > > > > How convenient (test) works too. > > > > So much for turbo boost theory. Nothing changed until I turned load > > balancing off at NODE. High end went to hell (gee), but low end... > > > > Benchmark Version Machine Run Date > > AIM Multiuser Benchmark - Suite VII "1.1" > > performance-no-node-load_balance Jan 28 11:20:12 2013 > > > > Tasks Jobs/Min JTI Real CPU Jobs/sec/task > > 1 436.3 100 13.9 3.9 7.2714 > > 5 2637.1 99 11.5 7.3 8.7903 > > 10 5415.5 99 11.2 11.3 9.0259 > > 20 10603.7 99 11.4 24.8 8.8364 > > 40 20066.2 99 12.1 40.5 8.3609 > > 80 35079.6 99 13.8 75.5 7.3082 > > 160 55884.7 98 17.3 145.6 5.8213 > > 320 79345.3 98 24.4 287.4 4.1326 > > If you're talking about those results from earlier: > > Benchmark Version Machine Run Date > AIM Multiuser Benchmark - Suite VII "1.1" performance Jan 28 > 08:09:20 2013 > > Tasks Jobs/Min JTI Real CPU Jobs/sec/task > 1 438.8 100 13.8 3.8 7.3135 > 5 2634.8 99 11.5 7.2 8.7826 > 10 5396.3 99 11.2 11.4 8.9938 > 20 10725.7 99 11.3 24.0 8.9381 > 40 20183.2 99 12.0 38.5 8.4097 > 80 35620.9 99 13.6 71.4 7.4210 > 160 57203.5 98 16.9 137.8 5.9587 > 320 81995.8 98 23.7 271.3 4.2706 > > then the above no_node-load_balance thing suffers a small-ish dip at 320 > tasks, yeah.
No no, that's not restricted to one node. It's just overloaded because I turned balancing off at the NODE domain level. > And AFAICR, the effect of disabling boosting will be visible in the > small count tasks cases anyway because if you saturate the cores with > tasks, the boosting algorithms tend to get the box out of boosting for > the simple reason that the power/perf headroom simply disappears due to > the SOC being busy. > > > 640 100294.8 98 38.7 570.9 2.6118 > > 1280 115998.2 97 66.9 1132.8 1.5104 > > 2560 125820.0 97 123.3 2256.6 0.8191 > > I dunno about those. maybe this is expected with so many tasks or do we > want to optimize that case further? When using all 4 nodes properly, that's still scaling. Here, I intentionally screwed up balancing to watch the low end. High end is expected wreckage. -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/
