From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Linux-Kernel mailing list <linux-kernel@vger.kernel.org>,
Linux Torvalds <torvalds@osdl.org>, Alan Cox <alan@redhat.com>
Subject: Re: [PATCH 1/1] x86_64: add config options to optimize for newer AMD processors
Date: Thu, 03 Oct 2013 09:42:59 -0400 [thread overview]
Message-ID: <524D7463.8080305@gmail.com> (raw)
In-Reply-To: <20130929213026.GF5426@pd.tnic>
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.
next prev parent reply other threads:[~2013-10-03 13:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 17:54 [PATCH 1/1] x86_64: add config options to optimize for newer AMD processors Austin S Hemmelgarn
2013-09-29 18:01 ` Borislav Petkov
2013-09-29 20:41 ` Austin S Hemmelgarn
2013-09-29 20:50 ` Borislav Petkov
2013-09-29 21:23 ` Austin S Hemmelgarn
2013-09-29 21:30 ` Borislav Petkov
2013-10-03 13:42 ` Austin S Hemmelgarn [this message]
[not found] ` <524D5DAC.3000004@gmail.com>
2013-10-03 16:27 ` Linus Torvalds
2013-10-03 16:57 ` Borislav Petkov
2013-10-03 18:12 ` Austin S Hemmelgarn
2013-10-03 18:28 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524D7463.8080305@gmail.com \
--to=ahferroin7@gmail.com \
--cc=alan@redhat.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox