From: Rik van Riel <riel@surriel.com>
To: linux-kernel@vger.kernel.org
Cc: 86@vger.kernel.org, luto@kernel.org, mingo@kernel.org,
tglx@linutronix.de, dave.hansen@linux.intel.com, efault@gmx.de,
songliubraving@fb.com, kernel-team@fb.com
Subject: [PATCH 0/7] x86,tlb,mm: make lazy TLB mode even lazier
Date: Wed, 20 Jun 2018 15:56:45 -0400 [thread overview]
Message-ID: <20180620195652.27251-1-riel@surriel.com> (raw)
Song noticed switch_mm_irqs_off taking a lot of CPU time in recent
kernels, using 1.9% of a 48 CPU system during a netperf run. Digging
into the profile, the atomic operations in cpumask_clear_cpu and
cpumask_set_cpu are responsible for about half of that CPU use.
However, the CPUs running netperf are simply switching back and
forth between netperf and the idle task, which does not require any
changes to the mm_cpumask if lazy TLB mode were used.
Additionally, the init_mm cpumask ends up being the most heavily
contended one in the system, for no reason at all.
Making really lazy TLB mode work again on modern kernels, by sending
a shootdown IPI only when page table pages are being unmapped, we get
back some performance.
Using a memcache style workload on Broadwell systems, these patches
result in about a 0.5% reduction of CPU use on the system. Numbers
on Haswell are inconclusive so far.
Song's netperf performance results:
w/o patchset:
Throughput: 1.74716e+06
perf profile:
+ 0.95% swapper [kernel.vmlinux] [k] switch_mm_irqs_off
+ 0.82% netserver [kernel.vmlinux] [k] switch_mm_irqs_off
w/ patchset:
Throughput: 1.76911e+06
perf profile:
+ 0.81% swapper [kernel.vmlinux] [k] switch_mm_irqs_off
With these patches, netserver no longer calls switch_mm_irqs_off,
and the CPU use of enter_lazy_tlb was below the 0.05% threshold of
statistics gathered by Song's scripts.
I am still working on a patch to also get rid of the continuous
pounding on mm->count during lazy TLB entry and exit, when the same
mm_struct is being used all the time. I do not have that working yet.
Until then, these patches provide a nice performance boost, as well
as a little memory savings by shrinking the size of mm_struct.
next reply other threads:[~2018-06-20 19:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 19:56 Rik van Riel [this message]
2018-06-20 19:56 ` [PATCH 1/7] mm: allocate mm_cpumask dynamically based on nr_cpu_ids Rik van Riel
2018-06-20 21:32 ` kbuild test robot
2018-06-21 20:18 ` Rik van Riel
2018-06-21 0:24 ` kbuild test robot
2018-06-22 15:10 ` Dave Hansen
2018-06-22 17:45 ` Rik van Riel
2018-06-20 19:56 ` [PATCH 2/7] x86,tlb: leave lazy TLB mode at page table free time Rik van Riel
2018-06-21 0:23 ` Rik van Riel
2018-06-22 14:58 ` Andy Lutomirski
2018-06-22 15:17 ` Rik van Riel
2018-06-20 19:56 ` [PATCH 3/7] x86,tlb: change tlbstate.is_lazy to tlbstate.state Rik van Riel
2018-06-22 17:01 ` Dave Hansen
2018-06-22 17:08 ` Rik van Riel
2018-06-20 19:56 ` [PATCH 4/7] x86,tlb: make lazy TLB mode lazier Rik van Riel
2018-06-22 15:04 ` Andy Lutomirski
2018-06-22 15:15 ` Rik van Riel
2018-06-22 15:34 ` Andy Lutomirski
2018-06-22 17:05 ` Dave Hansen
2018-06-22 17:16 ` Rik van Riel
2018-06-20 19:56 ` [PATCH 5/7] x86,tlb: only send page table free TLB flush to lazy TLB CPUs Rik van Riel
2018-06-22 17:23 ` Dave Hansen
2018-06-20 19:56 ` [PATCH 6/7] x86,mm: always use lazy TLB mode Rik van Riel
2018-06-20 19:56 ` [PATCH 7/7] x86,idle: do not leave mm in idle state Rik van Riel
2018-06-20 22:20 ` kbuild test robot
2018-06-21 0:25 ` Rik van Riel
2018-06-22 15:36 ` Andy Lutomirski
2018-06-22 15:53 ` Rik van Riel
2018-06-22 16:01 ` Andy Lutomirski
2018-06-22 20:18 ` Rik van Riel
2018-06-22 22:05 ` Andy Lutomirski
2018-06-23 0:55 ` Rik van Riel
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=20180620195652.27251-1-riel@surriel.com \
--to=riel@surriel.com \
--cc=86@vger.kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=efault@gmx.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.