On 2013-09-29 17:30, Borislav Petkov wrote: > On Sun, Sep 29, 2013 at 05:23:37PM -0400, Austin S Hemmelgarn wrote: >> I'm not saying that should just be included without substantiation, >> I simply mean that the reason to include it (as far as I am >> concerned) is that it doesn't break anything and provides something >> useful that isn't in the kernel already. > > If it doesn't bring any performance improvement - and I don't want > to rain on your parade but I think it won't, at least not enough to > warrant a serious look - there's absolutely no reason to add it. > > But hey, I'm always open to surprises! So surprise me! > > :-) >
Sorry it took me so long to get back to you about this. After doing some intensive testing, it appears that there is some improvement, but it is mostly in the scheduling code and syscalls. Most sysbench benchmarks only show improvement when running with more threads than processor cores; however, build jobs appear to be much improved. Building kernel 3.12-rc2 with allmodconfig using 8 jobs on a FX-8320 takes 22 minutes and 57 seconds on a kernel with CONFIG_MK8, 21 minutes and 35 seconds on a kernel with CONFIG_GENERIC, and 19 minutes and 11 seconds on a kernel with CONFIG_PILEDRIVER. I see similar results for a build of GCC 4.7 (45m1s, 41m39s, and 38m56s(. I would love to test it on my Athlon II system, but I can't afford to have any appreciable load on that system because I'm using it as a router/firewall, based on a look at the low level stuff though, I believe that it would still be at least a bit better with CONFIG_MAMDFAM10 than with CONFIG_GENERIC, and certainly better than CONFIG_MK8 (there are some big differences in the execution pipeline between K8 and family 10h). I don't know about you, but that sure seems to be a worthwhile performance increase to me. -- 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/
