Re: [PATCH 1/1] x86_64: add config options to optimize for newerAMD processors

[Austin S Hemmelgarn]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/