From: Mel Gorman <mgorman@suse.de>
To: Linux-MM <linux-mm@kvack.org>
Cc: Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
Minchan Kim <minchan@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Andi Kleen <andi@firstfloor.org>,
LKML <linux-kernel@vger.kernel.org>, Mel Gorman <mgorman@suse.de>
Subject: [PATCH 0/3] TLB flush multiple pages per IPI v4
Date: Sat, 25 Apr 2015 18:45:39 +0100 [thread overview]
Message-ID: <1429983942-4308-1-git-send-email-mgorman@suse.de> (raw)
The big change here is that I dropped the patch that batches TLB flushes
from migration context. After V3, I realised that there are non-trivial
corner cases there that deserve treatment in their own series. It did not
help that I could not find a workload that was both migration and IPI
intensive. The common case for IPIs during reclaim is kswapd unmapping
pages which guarantees IPIs. In migration, at least some of the pages
being migrated will belong to the process itself.
The main issue is that migration cannot have any cached TLB entries after
migration completes. Once the migration PTE is removed then writes can happen
to that new page. The old TLB entry could see stale reads until it's flushed
which is different to the reclaim case. This is difficult to get around. We
cannot just unmap in advance because then there are no migration entries
to restore and there would be minor faults post-migration. We can't batch
restore the migration entries because the page lock must be held during
migration or BUG_ONs get triggered. Batching TLB flushes safely requires
a major rethink of how migration works so lets deal with reclaim first on
its own, preferably in the context of a workload that is both migration
and IPI intensive.
The patch that increased the batching size was also removed because there
is no advantage when TLBs are flushed before freeing the page. To increase
batching we would have to alter how many pages are isolated from the LRU
which would be a different patch series.
Most reviewed-bys had to be dropped as the patches changed too much to
preserve them.
Changelog since V3
o Drop batching of TLB flush from migration
o Redo how larger batching is managed
o Batch TLB flushes when writable entries exist
When unmapping pages it is necessary to flush the TLB. If that page was
accessed by another CPU then an IPI is used to flush the remote CPU. That
is a lot of IPIs if kswapd is scanning and unmapping >100K pages per second.
There already is a window between when a page is unmapped and when it is
TLB flushed. This series simply increases the window so multiple pages can
be flushed using a single IPI.
Patch 1 simply made the rest of the series easier to write as ftrace
could identify all the senders of TLB flush IPIS.
Patch 2 collects a list of PFNs and sends one IPI to flush them all
Patch 3 tracks when there potentially are writable TLB entries that
need to be batched differently
The performance impact is documented in the changelogs but in the optimistic
case on a 4-socket machine the full series reduces interrupts from 900K
interrupts/second to 60K interrupts/second.
arch/x86/Kconfig | 1 +
arch/x86/include/asm/tlbflush.h | 2 +
arch/x86/mm/tlb.c | 1 +
include/linux/init_task.h | 8 +++
include/linux/mm_types.h | 1 +
include/linux/rmap.h | 3 +
include/linux/sched.h | 15 +++++
include/trace/events/tlb.h | 3 +-
init/Kconfig | 8 +++
kernel/fork.c | 5 ++
kernel/sched/core.c | 3 +
mm/internal.h | 15 +++++
mm/rmap.c | 119 +++++++++++++++++++++++++++++++++++++++-
mm/vmscan.c | 45 ++++++++++++++-
14 files changed, 224 insertions(+), 5 deletions(-)
--
2.3.5
Mel Gorman (3):
x86, mm: Trace when an IPI is about to be sent
mm: Send one IPI per CPU to TLB flush multiple pages that were
recently unmapped
mm: Defer flush of writable TLB entries
arch/x86/Kconfig | 1 +
arch/x86/include/asm/tlbflush.h | 2 +
arch/x86/mm/tlb.c | 1 +
include/linux/init_task.h | 8 +++
include/linux/mm_types.h | 1 +
include/linux/rmap.h | 3 +
include/linux/sched.h | 15 +++++
include/trace/events/tlb.h | 3 +-
init/Kconfig | 8 +++
kernel/fork.c | 5 ++
kernel/sched/core.c | 3 +
mm/internal.h | 15 +++++
mm/rmap.c | 119 +++++++++++++++++++++++++++++++++++++++-
mm/vmscan.c | 30 +++++++++-
14 files changed, 210 insertions(+), 4 deletions(-)
--
2.3.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2015-04-25 17:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-25 17:45 Mel Gorman [this message]
2015-04-25 17:45 ` [PATCH 1/3] x86, mm: Trace when an IPI is about to be sent Mel Gorman
2015-04-25 17:45 ` [PATCH 2/3] mm: Send one IPI per CPU to TLB flush multiple pages that were recently unmapped Mel Gorman
2015-04-27 2:48 ` Rik van Riel
2015-04-25 17:45 ` [PATCH 3/3] mm: Defer flush of writable TLB entries Mel Gorman
2015-04-27 2:50 ` Rik van Riel
2015-08-31 16:20 ` [PATCH 0/3] TLB flush multiple pages per IPI v4 Sébastien Wacquiez
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=1429983942-4308-1-git-send-email-mgorman@suse.de \
--to=mgorman@suse.de \
--cc=andi@firstfloor.org \
--cc=dave.hansen@intel.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
/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).