From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: Linux 3.19-rc3
Date: Mon, 12 Jan 2015 19:24:51 +0000 [thread overview]
Message-ID: <20150112192451.GQ13360@arm.com> (raw)
In-Reply-To: <CA+55aFw=urngjyQvuOWHP1BBe-tNKy0E4DC0c5PwP+XuvpSmEg@mail.gmail.com>
On Mon, Jan 12, 2015 at 07:07:12PM +0000, Linus Torvalds wrote:
> On Tue, Jan 13, 2015 at 8:06 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So I'm ok with it, as long as we don't have a performance regression.
> >
> > Your "don't bother freeing when the batch is empty" should hopefully
> > be fine. Dave, does that work for your case?
>
> Oh, and Dave just replied that it's ok. So should I just take it
> directly, or expect it through the arm64 tree? Either works for me.
Although I do have a couple of arm64 fixes on the radar, it'd be quicke
if you just take the patch. I added a commit log/SoB below.
Cheers,
Will
--->8
>From bcf792ffc9ce29415261d2055954b883c5bec978 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon@arm.com>
Date: Mon, 12 Jan 2015 19:10:55 +0000
Subject: [PATCH] mm: mmu_gather: use tlb->end != 0 only for TLB invalidation
When batching up address ranges for TLB invalidation, we check tlb->end
!= 0 to indicate that some pages have actually been unmapped.
As of commit f045bbb9fa1b ("mmu_gather: fix over-eager
tlb_flush_mmu_free() calling"), we use the same check for freeing these
pages in order to avoid a performance regression where we call
free_pages_and_swap_cache even when no pages are actually queued up.
Unfortunately, the range could have been reset (tlb->end = 0) by
tlb_end_vma, which has been shown to cause memory leaks on arm64.
Furthermore, investigation into these leaks revealed that the fullmm
case on task exit no longer invalidates the TLB, by virtue of tlb->end
== 0 (in 3.18, need_flush would have been set).
This patch resolves the problem by reverting f045bbb9fa1b, using
tlb->local.nr as the predicate for page freeing in tlb_flush_mmu_free
and ensuring that tlb->end is initialised to a non-zero value in the
fullmm case.
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Dave Hansen <dave@sr71.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
include/asm-generic/tlb.h | 8 ++++++--
mm/memory.c | 8 ++++----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 08848050922e..db284bff29dc 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -136,8 +136,12 @@ static inline void __tlb_adjust_range(struct mmu_gather *tlb,
static inline void __tlb_reset_range(struct mmu_gather *tlb)
{
- tlb->start = TASK_SIZE;
- tlb->end = 0;
+ if (tlb->fullmm) {
+ tlb->start = tlb->end = ~0;
+ } else {
+ tlb->start = TASK_SIZE;
+ tlb->end = 0;
+ }
}
/*
diff --git a/mm/memory.c b/mm/memory.c
index c6565f00fb38..54f3a9b00956 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -235,6 +235,9 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
{
+ if (!tlb->end)
+ return;
+
tlb_flush(tlb);
mmu_notifier_invalidate_range(tlb->mm, tlb->start, tlb->end);
#ifdef CONFIG_HAVE_RCU_TABLE_FREE
@@ -247,7 +250,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
{
struct mmu_gather_batch *batch;
- for (batch = &tlb->local; batch; batch = batch->next) {
+ for (batch = &tlb->local; batch && batch->nr; batch = batch->next) {
free_pages_and_swap_cache(batch->pages, batch->nr);
batch->nr = 0;
}
@@ -256,9 +259,6 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
void tlb_flush_mmu(struct mmu_gather *tlb)
{
- if (!tlb->end)
- return;
-
tlb_flush_mmu_tlbonly(tlb);
tlb_flush_mmu_free(tlb);
}
--
2.1.4
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Laszlo Ersek <lersek@redhat.com>,
Mark Langsdorf <mlangsdo@redhat.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Steve Capper <steve.capper@linaro.org>,
"vishnu.ps@samsung.com" <vishnu.ps@samsung.com>,
main kernel list <linux-kernel@vger.kernel.org>,
arm kernel list <linux-arm-kernel@lists.infradead.org>,
Kyle McMartin <kmcmarti@redhat.com>, Dave Hansen <dave@sr71.net>
Subject: Re: Linux 3.19-rc3
Date: Mon, 12 Jan 2015 19:24:51 +0000 [thread overview]
Message-ID: <20150112192451.GQ13360@arm.com> (raw)
In-Reply-To: <CA+55aFw=urngjyQvuOWHP1BBe-tNKy0E4DC0c5PwP+XuvpSmEg@mail.gmail.com>
On Mon, Jan 12, 2015 at 07:07:12PM +0000, Linus Torvalds wrote:
> On Tue, Jan 13, 2015 at 8:06 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So I'm ok with it, as long as we don't have a performance regression.
> >
> > Your "don't bother freeing when the batch is empty" should hopefully
> > be fine. Dave, does that work for your case?
>
> Oh, and Dave just replied that it's ok. So should I just take it
> directly, or expect it through the arm64 tree? Either works for me.
Although I do have a couple of arm64 fixes on the radar, it'd be quicke
if you just take the patch. I added a commit log/SoB below.
Cheers,
Will
--->8
>From bcf792ffc9ce29415261d2055954b883c5bec978 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon@arm.com>
Date: Mon, 12 Jan 2015 19:10:55 +0000
Subject: [PATCH] mm: mmu_gather: use tlb->end != 0 only for TLB invalidation
When batching up address ranges for TLB invalidation, we check tlb->end
!= 0 to indicate that some pages have actually been unmapped.
As of commit f045bbb9fa1b ("mmu_gather: fix over-eager
tlb_flush_mmu_free() calling"), we use the same check for freeing these
pages in order to avoid a performance regression where we call
free_pages_and_swap_cache even when no pages are actually queued up.
Unfortunately, the range could have been reset (tlb->end = 0) by
tlb_end_vma, which has been shown to cause memory leaks on arm64.
Furthermore, investigation into these leaks revealed that the fullmm
case on task exit no longer invalidates the TLB, by virtue of tlb->end
== 0 (in 3.18, need_flush would have been set).
This patch resolves the problem by reverting f045bbb9fa1b, using
tlb->local.nr as the predicate for page freeing in tlb_flush_mmu_free
and ensuring that tlb->end is initialised to a non-zero value in the
fullmm case.
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Dave Hansen <dave@sr71.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
include/asm-generic/tlb.h | 8 ++++++--
mm/memory.c | 8 ++++----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 08848050922e..db284bff29dc 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -136,8 +136,12 @@ static inline void __tlb_adjust_range(struct mmu_gather *tlb,
static inline void __tlb_reset_range(struct mmu_gather *tlb)
{
- tlb->start = TASK_SIZE;
- tlb->end = 0;
+ if (tlb->fullmm) {
+ tlb->start = tlb->end = ~0;
+ } else {
+ tlb->start = TASK_SIZE;
+ tlb->end = 0;
+ }
}
/*
diff --git a/mm/memory.c b/mm/memory.c
index c6565f00fb38..54f3a9b00956 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -235,6 +235,9 @@ void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
static void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
{
+ if (!tlb->end)
+ return;
+
tlb_flush(tlb);
mmu_notifier_invalidate_range(tlb->mm, tlb->start, tlb->end);
#ifdef CONFIG_HAVE_RCU_TABLE_FREE
@@ -247,7 +250,7 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
{
struct mmu_gather_batch *batch;
- for (batch = &tlb->local; batch; batch = batch->next) {
+ for (batch = &tlb->local; batch && batch->nr; batch = batch->next) {
free_pages_and_swap_cache(batch->pages, batch->nr);
batch->nr = 0;
}
@@ -256,9 +259,6 @@ static void tlb_flush_mmu_free(struct mmu_gather *tlb)
void tlb_flush_mmu(struct mmu_gather *tlb)
{
- if (!tlb->end)
- return;
-
tlb_flush_mmu_tlbonly(tlb);
tlb_flush_mmu_free(tlb);
}
--
2.1.4
next prev parent reply other threads:[~2015-01-12 19:24 UTC|newest]
Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-06 1:46 Linux 3.19-rc3 Linus Torvalds
2015-01-06 2:46 ` Dave Jones
2015-01-06 8:18 ` Takashi Iwai
2015-01-06 9:45 ` Jiri Kosina
2015-01-08 12:51 ` Mark Langsdorf
2015-01-08 12:51 ` Mark Langsdorf
2015-01-08 13:45 ` Catalin Marinas
2015-01-08 13:45 ` Catalin Marinas
2015-01-08 17:29 ` Mark Langsdorf
2015-01-08 17:29 ` Mark Langsdorf
2015-01-08 17:34 ` Catalin Marinas
2015-01-08 17:34 ` Catalin Marinas
2015-01-08 18:48 ` Mark Langsdorf
2015-01-08 18:48 ` Mark Langsdorf
2015-01-08 19:21 ` Linus Torvalds
2015-01-08 19:21 ` Linus Torvalds
2015-01-09 23:27 ` Catalin Marinas
2015-01-09 23:27 ` Catalin Marinas
2015-01-10 0:35 ` Kirill A. Shutemov
2015-01-10 0:35 ` Kirill A. Shutemov
2015-01-10 2:27 ` Linus Torvalds
2015-01-10 2:27 ` Linus Torvalds
2015-01-10 2:51 ` David Lang
2015-01-10 2:51 ` David Lang
2015-01-10 3:06 ` Linus Torvalds
2015-01-10 3:06 ` Linus Torvalds
2015-01-10 10:46 ` Andreas Mohr
2015-01-10 10:46 ` Andreas Mohr
2015-01-10 19:42 ` Linus Torvalds
2015-01-10 19:42 ` Linus Torvalds
2015-01-13 3:33 ` Rik van Riel
2015-01-13 3:33 ` Rik van Riel
2015-01-13 10:28 ` Catalin Marinas
2015-01-13 10:28 ` Catalin Marinas
2015-01-10 3:17 ` Tony Luck
2015-01-10 3:17 ` Tony Luck
2015-01-10 20:16 ` Arnd Bergmann
2015-01-10 20:16 ` Arnd Bergmann
2015-01-10 21:00 ` Linus Torvalds
2015-01-10 21:00 ` Linus Torvalds
2015-01-10 21:36 ` Arnd Bergmann
2015-01-10 21:36 ` Arnd Bergmann
2015-01-10 21:48 ` Linus Torvalds
2015-01-10 21:48 ` Linus Torvalds
2015-01-12 11:37 ` Kirill A. Shutemov
2015-01-12 11:37 ` Kirill A. Shutemov
2015-01-12 12:18 ` Catalin Marinas
2015-01-12 12:18 ` Catalin Marinas
2015-01-12 13:57 ` Arnd Bergmann
2015-01-12 13:57 ` Arnd Bergmann
2015-01-12 14:23 ` Catalin Marinas
2015-01-12 14:23 ` Catalin Marinas
2015-01-12 15:42 ` Arnd Bergmann
2015-01-12 15:42 ` Arnd Bergmann
2015-01-12 11:53 ` Catalin Marinas
2015-01-12 11:53 ` Catalin Marinas
2015-01-12 13:15 ` Arnd Bergmann
2015-01-12 13:15 ` Arnd Bergmann
2015-01-08 15:08 ` Michal Hocko
2015-01-08 15:08 ` Michal Hocko
2015-01-08 15:08 ` Michal Hocko
2015-01-08 16:37 ` Mark Langsdorf
2015-01-08 16:37 ` Mark Langsdorf
2015-01-08 16:37 ` Mark Langsdorf
2015-01-09 15:56 ` Michal Hocko
2015-01-09 15:56 ` Michal Hocko
2015-01-09 15:56 ` Michal Hocko
2015-01-09 12:13 ` Mark Rutland
2015-01-09 12:13 ` Mark Rutland
2015-01-09 14:19 ` Steve Capper
2015-01-09 14:19 ` Steve Capper
2015-01-09 14:27 ` Mark Langsdorf
2015-01-09 14:27 ` Mark Langsdorf
2015-01-09 17:57 ` Mark Rutland
2015-01-09 17:57 ` Mark Rutland
2015-01-09 18:37 ` Marc Zyngier
2015-01-09 18:37 ` Marc Zyngier
2015-01-09 19:43 ` Will Deacon
2015-01-09 19:43 ` Will Deacon
2015-01-10 3:29 ` Laszlo Ersek
2015-01-10 3:29 ` Laszlo Ersek
2015-01-10 4:39 ` Linus Torvalds
2015-01-10 4:39 ` Linus Torvalds
2015-01-10 13:37 ` Will Deacon
2015-01-10 13:37 ` Will Deacon
2015-01-10 19:47 ` Laszlo Ersek
2015-01-10 19:47 ` Laszlo Ersek
2015-01-10 19:56 ` Linus Torvalds
2015-01-10 19:56 ` Linus Torvalds
2015-01-10 20:08 ` Laszlo Ersek
2015-01-10 20:08 ` Laszlo Ersek
2015-01-10 19:51 ` Linus Torvalds
2015-01-10 19:51 ` Linus Torvalds
2015-01-12 12:42 ` Will Deacon
2015-01-12 12:42 ` Will Deacon
2015-01-12 13:22 ` Mark Langsdorf
2015-01-12 13:22 ` Mark Langsdorf
2015-01-12 19:03 ` Dave Hansen
2015-01-12 19:03 ` Dave Hansen
2015-01-12 19:06 ` Linus Torvalds
2015-01-12 19:06 ` Linus Torvalds
2015-01-12 19:07 ` Linus Torvalds
2015-01-12 19:07 ` Linus Torvalds
2015-01-12 19:24 ` Will Deacon [this message]
2015-01-12 19:24 ` Will Deacon
2015-01-10 15:22 ` Kyle McMartin
2015-01-10 15:22 ` Kyle McMartin
-- strict thread matches above, loose matches on Subject: below --
2015-01-06 4:49 Sedat Dilek
2015-01-06 9:34 ` Sedat Dilek
2015-01-06 9:56 ` Takashi Iwai
2015-01-06 10:06 ` Sedat Dilek
2015-01-06 10:28 ` Takashi Iwai
2015-01-06 10:31 ` Sedat Dilek
2015-01-06 10:37 ` Takashi Iwai
2015-01-06 10:42 ` Sedat Dilek
2015-01-06 9:59 ` Peter Zijlstra
2015-01-06 9:40 ` Peter Zijlstra
2015-01-06 9:42 ` Sedat Dilek
2015-01-06 9:57 ` Sedat Dilek
2015-01-06 10:06 ` Peter Zijlstra
2015-01-06 10:18 ` Sedat Dilek
2015-01-06 11:01 ` Peter Zijlstra
2015-01-06 11:07 ` Kent Overstreet
2015-01-06 11:25 ` Sedat Dilek
2015-01-06 11:40 ` Kent Overstreet
2015-01-06 12:51 ` Sedat Dilek
2015-01-06 11:42 ` Peter Zijlstra
2015-01-06 11:48 ` Peter Zijlstra
2015-01-06 12:01 ` Kent Overstreet
2015-01-06 12:20 ` Peter Zijlstra
2015-01-06 12:45 ` Kent Overstreet
2015-01-06 12:55 ` Peter Hurley
2015-01-06 17:38 ` Paul E. McKenney
2015-01-06 17:58 ` Peter Hurley
2015-01-06 19:25 ` Paul E. McKenney
2015-01-06 19:57 ` Peter Hurley
2015-01-06 20:47 ` Paul E. McKenney
2015-01-20 0:30 ` Paul E. McKenney
2015-01-20 14:03 ` Peter Hurley
2015-02-02 16:11 ` Paul E. McKenney
2015-02-02 19:03 ` Peter Hurley
2015-02-02 19:33 ` Paul E. McKenney
2015-01-06 11:56 ` Kent Overstreet
2015-01-06 12:16 ` Peter Zijlstra
2015-01-06 12:43 ` Kent Overstreet
2015-01-06 13:03 ` Peter Zijlstra
2015-01-06 13:28 ` Kent Overstreet
2015-01-13 15:23 ` Peter Zijlstra
2015-01-06 11:58 ` Peter Zijlstra
2015-01-06 12:18 ` Kent Overstreet
2015-01-16 16:56 ` Peter Hurley
2015-01-16 17:00 ` Chris Mason
2015-01-16 18:58 ` Peter Hurley
2015-01-06 10:29 ` Sedat Dilek
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=20150112192451.GQ13360@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 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.