archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <>
To: John <>
Cc: "H. Peter Anvin" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	lkml <>,
	Linus Torvalds <>,
	Peter Zijlstra <>
Subject: Re: [PATCH] expand micro-optimizations in kernel to newer model CPUs
Date: Mon, 16 Dec 2013 15:28:16 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* John <> wrote:

> This patch has been tested on and known to work with kernel versions 
> from 3.2 up to the latest git version (pulled on 12/14/2013).
> This patch will expand the number of microarchitectures to include 
> new processors including: AMD K10-family, AMD Family 10h 
> (Barcelona), AMD Family 14h (Bobcat), AMD Family 15h (Bulldozer), 
> AMD Family 15h (Piledriver), AMD Family 16h (Jaguar), Intel 1st Gen 
> Core i3/i5/i7 (Nehalem), Intel 2nd Gen Core i3/i5/i7 (Sandybridge), 
> Intel 3rd Gen Core i3/i5/i7 (Ivybridge), and Intel 4th Gen Core 
> i3/i5/i7 (Haswell). It also offers the compiler the 'native' flag.

So let me (again) follow Linus's general advice to say 'no' to patches 
more forcefully, so that people don't go down potential dead ends for 
too long time without strong negative feedback from upstream. :-)

This series does not look convincing enough to me. My complaints:

 - I'm not convinced the numbers are right. Rarely are such tiny
   compiler optimizations measureable in integer-only kernel code ...
   Too noisy benchmarks were used. More precise measurements done by
   Boris showed no statistically significant improvements:

 - Modern CPUs have inherently high noise: boot-to-boot variance is 
   often higher on modern systems with large caches than the speedup 
   claimed by optimization options ...

 - I'm not convinced the whole concept is long term maintainable to 
   begin with. When Linux on x86 began we used to have just 2-3 major 
   CPU models to care about, so it made sense. That count grew rapidly 
   and today we havedozens (if not hundreds) of models, families and
   variants and our 'optimization' options are just one big 
   fragmented, rarely tested mess with essentially random compiler 
   flags thrown at it.

 - The cost of getting optimizations wrong by going away from sane 
   defaults is probably high as well: see the case where Boris
   measured a regression from an 'optimization' option.

 - GCC itself changes as well, so a seemingly good but rarely used
   optimization flag could get out of sync and hurt performance on 
   rarer, rarely tested CPU models. It's sometimes safer to go with 
   the herd and use good, sensible defaults in most situations.

For those reasons I think we should just strip out all the current 
outdated micro-management of models/ and go to more logical, much 
broader optimization categories such as:

   "Optimize for modern Intel CPUs"
   "Optimize for modern AMD CPUs"

because most of the day to day measurement and testing work is 
concentrated on modern CPUs.

We might not even want to make a vendor differentiation there and just 
do a generic:

   "Optimize for modern x86 CPUs"
With perhaps a "workarounds" sub-option opening up:

   "Optimization workarounds" [x]
      "Intel Atom CPUs" [x]

Because occasionally there will be oddball yet common CPUs that need 
starkly different optimizations/workarounds. Naming it a 'workaround' 
creates an incentive to return such platforms to the common options.

I.e. handle and document the exceptions, and try to minimize them - 
instead of trying to enumerate every CPU model which is IMHO a losing 
game ...

[ If that is done then we also need much more statistically convincing
  methods to test how well a kernel's compiler options perform.



  parent reply	other threads:[~2013-12-16 14:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-08 15:53 [PATCH] expand micro-optimizations in kernel to newer model CPUs John
2013-12-10  3:51 ` David Heidelberger
2013-12-13 12:37   ` Austin S Hemmelgarn
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
2013-12-15 12:00             ` John
2013-12-15 12:27               ` Richard Weinberger
2013-12-15 12:42                 ` John
2013-12-15 13:23                   ` Borislav Petkov
2013-12-15 17:31                   ` Richard Weinberger
2013-12-16 14:28               ` Ingo Molnar [this message]
2013-12-17 12:59                 ` Austin S Hemmelgarn
2013-12-15 12:23     ` John

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).