stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Mel Gorman <mgorman@suse.de>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Alex Shi <alex.shi@linaro.org>, Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: [PATCH 3.13 25/40] x86: mm: change tlb_flushall_shift for IvyBridge
Date: Tue, 18 Feb 2014 14:47:26 -0800	[thread overview]
Message-ID: <20140218224434.046361468@linuxfoundation.org> (raw)
In-Reply-To: <20140218224433.337299968@linuxfoundation.org>

3.13-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Mel Gorman <mgorman@suse.de>

commit f98b7a772ab51b52ca4d2a14362fc0e0c8a2e0f3 upstream.

There was a large performance regression that was bisected to
commit 611ae8e3 ("x86/tlb: enable tlb flush range support for
x86").  This patch simply changes the default balance point
between a local and global flush for IvyBridge.

In the interest of allowing the tests to be reproduced, this
patch was tested using mmtests 0.15 with the following
configurations

	configs/config-global-dhp__tlbflush-performance
	configs/config-global-dhp__scheduler-performance
	configs/config-global-dhp__network-performance

Results are from two machines

Ivybridge   4 threads:  Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
Ivybridge   8 threads:  Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

Page fault microbenchmark showed nothing interesting.

Ebizzy was configured to run multiple iterations and threads.
Thread counts ranged from 1 to NR_CPUS*2. For each thread count,
it ran 100 iterations and each iteration lasted 10 seconds.

Ivybridge 4 threads
                    3.13.0-rc7            3.13.0-rc7
                       vanilla           altshift-v3
Mean   1     6395.44 (  0.00%)     6789.09 (  6.16%)
Mean   2     7012.85 (  0.00%)     8052.16 ( 14.82%)
Mean   3     6403.04 (  0.00%)     6973.74 (  8.91%)
Mean   4     6135.32 (  0.00%)     6582.33 (  7.29%)
Mean   5     6095.69 (  0.00%)     6526.68 (  7.07%)
Mean   6     6114.33 (  0.00%)     6416.64 (  4.94%)
Mean   7     6085.10 (  0.00%)     6448.51 (  5.97%)
Mean   8     6120.62 (  0.00%)     6462.97 (  5.59%)

Ivybridge 8 threads
                     3.13.0-rc7            3.13.0-rc7
                        vanilla           altshift-v3
Mean   1      7336.65 (  0.00%)     7787.02 (  6.14%)
Mean   2      8218.41 (  0.00%)     9484.13 ( 15.40%)
Mean   3      7973.62 (  0.00%)     8922.01 ( 11.89%)
Mean   4      7798.33 (  0.00%)     8567.03 (  9.86%)
Mean   5      7158.72 (  0.00%)     8214.23 ( 14.74%)
Mean   6      6852.27 (  0.00%)     7952.45 ( 16.06%)
Mean   7      6774.65 (  0.00%)     7536.35 ( 11.24%)
Mean   8      6510.50 (  0.00%)     6894.05 (  5.89%)
Mean   12     6182.90 (  0.00%)     6661.29 (  7.74%)
Mean   16     6100.09 (  0.00%)     6608.69 (  8.34%)

Ebizzy hits the worst case scenario for TLB range flushing every
time and it shows for these Ivybridge CPUs at least that the
default choice is a poor on.  The patch addresses the problem.

Next was a tlbflush microbenchmark written by Alex Shi at
http://marc.info/?l=linux-kernel&m=133727348217113 .  It
measures access costs while the TLB is being flushed.  The
expectation is that if there are always full TLB flushes that
the benchmark would suffer and it benefits from range flushing

There are 320 iterations of the test per thread count.  The
number of entries is randomly selected with a min of 1 and max
of 512.  To ensure a reasonably even spread of entries, the full
range is broken up into 8 sections and a random number selected
within that section.

iteration 1, random number between 0-64
iteration 2, random number between 64-128 etc

This is still a very weak methodology.  When you do not know
what are typical ranges, random is a reasonable choice but it
can be easily argued that the opimisation was for smaller ranges
and an even spread is not representative of any workload that
matters.  To improve this, we'd need to know the probability
distribution of TLB flush range sizes for a set of workloads
that are considered "common", build a synthetic trace and feed
that into this benchmark.  Even that is not perfect because it
would not account for the time between flushes but there are
limits of what can be reasonably done and still be doing
something useful.  If a representative synthetic trace is
provided then this benchmark could be revisited and the shift values retuned.

Ivybridge 4 threads
                        3.13.0-rc7            3.13.0-rc7
                           vanilla           altshift-v3
Mean       1       10.50 (  0.00%)       10.50 (  0.03%)
Mean       2       17.59 (  0.00%)       17.18 (  2.34%)
Mean       3       22.98 (  0.00%)       21.74 (  5.41%)
Mean       5       47.13 (  0.00%)       46.23 (  1.92%)
Mean       8       43.30 (  0.00%)       42.56 (  1.72%)

Ivybridge 8 threads
                         3.13.0-rc7            3.13.0-rc7
                            vanilla           altshift-v3
Mean       1         9.45 (  0.00%)        9.36 (  0.93%)
Mean       2         9.37 (  0.00%)        9.70 ( -3.54%)
Mean       3         9.36 (  0.00%)        9.29 (  0.70%)
Mean       5        14.49 (  0.00%)       15.04 ( -3.75%)
Mean       8        41.08 (  0.00%)       38.73 (  5.71%)
Mean       13       32.04 (  0.00%)       31.24 (  2.49%)
Mean       16       40.05 (  0.00%)       39.04 (  2.51%)

For both CPUs, average access time is reduced which is good as
this is the benchmark that was used to tune the shift values in
the first place albeit it is now known *how* the benchmark was
used.

The scheduler benchmarks were somewhat inconclusive.  They
showed gains and losses and makes me reconsider how stable those
benchmarks really are or if something else might be interfering
with the test results recently.

Network benchmarks were inconclusive.  Almost all results were
flat except for netperf-udp tests on the 4 thread machine.
These results were unstable and showed large variations between
reboots.  It is unknown if this is a recent problems but I've
noticed before that netperf-udp results tend to vary.

Based on these results, changing the default for Ivybridge seems
like a logical choice.

Signed-off-by: Mel Gorman <mgorman@suse.de>
Tested-by: Davidlohr Bueso <davidlohr@hp.com>
Reviewed-by: Alex Shi <alex.shi@linaro.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-cqnadffh1tiqrshthRj3Esge@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/cpu/intel.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -628,7 +628,7 @@ static void intel_tlb_flushall_shift_set
 		tlb_flushall_shift = 5;
 		break;
 	case 0x63a: /* Ivybridge */
-		tlb_flushall_shift = 1;
+		tlb_flushall_shift = 2;
 		break;
 	default:
 		tlb_flushall_shift = 6;



  parent reply	other threads:[~2014-02-18 22:47 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 22:47 [PATCH 3.13 00/40] 3.13.4-stable review Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 01/40] SELinux: Fix kernel BUG on empty security contexts Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 02/40] Btrfs: disable snapshot aware defrag for now Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 03/40] crypto: s390 - fix concurrency issue in aes-ctr mode Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 04/40] crypto: s390 - fix des and des3_ede cbc concurrency issue Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 05/40] crypto: s390 - fix des and des3_ede ctr " Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 06/40] NFSv4.1: nfs4_destroy_session must call rpc_destroy_waitqueue Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 07/40] NFSv4: Fix memory corruption in nfs4_proc_open_confirm Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 08/40] regulator: core: Correct default return value for full constraints Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 09/40] irqchip: armada-370-xp: fix IPI race condition Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 10/40] irqchip: armada-370-xp: fix MSI " Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 11/40] arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 12/40] arm64: atomics: fix use of acquire + release for full barrier semantics Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 13/40] arm64: vdso: prevent ld from aligning PT_LOAD segments to 64k Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 14/40] arm64: Invalidate the TLB when replacing pmd entries during boot Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 15/40] arm64: vdso: fix coarse clock handling Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 16/40] arm64: add DSB after icache flush in __flush_icache_all() Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 17/40] ALSA: usb-audio: Add missing kconfig dependecy Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 18/40] ALSA: hda - Fix missing VREF setup for Mac Pro 1,1 Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 19/40] ALSA: hda - Fix silent output on Toshiba Satellite L40 Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 20/40] ALSA: hda - Add missing mixer widget for AD1983 Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 21/40] ALSA: hda - Improve loopback path lookups " Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 22/40] mm/swap: fix race on swap_info reuse between swapoff and swapon Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 23/40] mm: __set_page_dirty_nobuffers() uses spin_lock_irqsave() instead of spin_lock_irq() Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 24/40] mm: __set_page_dirty uses spin_lock_irqsave instead of spin_lock_irq Greg Kroah-Hartman
2014-02-18 22:47 ` Greg Kroah-Hartman [this message]
2014-02-18 22:47 ` [PATCH 3.13 26/40] [media] af9035: add ID [2040:f900] Hauppauge WinTV-MiniStick 2 Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 27/40] [media] mxl111sf: Fix unintentional garbage stack read Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 29/40] [media] Revert "[media] videobuf_vm_{open,close} race fixes" Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 30/40] [media] cx24117: use a valid dev pointer for dev_err printout Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 31/40] x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 32/40] genirq: Generic irq chip requires IRQ_DOMAIN Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 33/40] pinctrl: at91: use locked variant of irq_set_handler Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 34/40] pinctrl: imx27: fix wrong offset to ICONFB Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 35/40] pinctrl: imx27: fix offset calculation in imx_read_2bit Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 36/40] pinctrl: vt8500: Change devicetree data parsing Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 37/40] pinctrl: protect pinctrl_list add Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 38/40] bcache: fix BUG_ON due to integer overflow with GC_SECTORS_USED Greg Kroah-Hartman
2014-02-18 22:47 ` [PATCH 3.13 39/40] intel_pstate: Take core C0 time into account for core busy calculation Greg Kroah-Hartman
2014-02-19 12:52   ` Stefan Lippers-Hollmann
2014-02-19 16:41     ` Dirk Brandewie
2014-02-18 22:47 ` [PATCH 3.13 40/40] ARM: imx6: Initialize low-power mode early again Greg Kroah-Hartman
2014-02-19  4:30 ` [PATCH 3.13 00/40] 3.13.4-stable review Guenter Roeck
2014-02-20 18:32   ` Greg Kroah-Hartman
2014-02-20 23:23     ` Guenter Roeck
2014-02-20 23:32       ` Greg Kroah-Hartman
2014-02-21  2:49         ` Guenter Roeck
2014-02-20  0:16 ` Shuah Khan
2014-02-20  0:36   ` Mark Brown
2014-02-20  1:20     ` Shuah Khan
2014-02-20  2:34       ` Mark Brown
2014-02-20 13:40         ` Shuah Khan
2014-02-20 14:45           ` Mark Brown
2014-02-20 18:29   ` Greg Kroah-Hartman
2014-02-20 10:26 ` Satoru Takeuchi
2014-02-20 18:31   ` Greg Kroah-Hartman

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=20140218224434.046361468@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linaro.org \
    --cc=davidlohr@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).