All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
	Minchan Kim <minchan@kernel.org>,
	Andi Kleen <andi@firstfloor.org>, H Peter Anvin <hpa@zytor.com>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/3] TLB flush multiple pages per IPI v5
Date: Tue, 9 Jun 2015 23:35:09 +0100	[thread overview]
Message-ID: <20150609223509.GX26425@suse.de> (raw)
In-Reply-To: <20150609223203.GW26425@suse.de>

On Tue, Jun 09, 2015 at 11:32:03PM +0100, Mel Gorman wrote:
> On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote:
> > On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> > >
> > > The 0 cycle TLB miss was also interesting.  It goes back up to something
> > > reasonable if I put the mb()/mfence's back.
> > 
> > So I've said it before, and I'll say it again: Intel does really well
> > on TLB fills.
> > 
> > The reason is partly historical, with Win95 doing a ton of TLB
> > invalidation (I think every single GDI call ended up invalidating the
> > TLB, so under some important Windows benchmarks of the time, you
> > literally had a TLB flush every 10k instructions!).
> > 
> > But partly it is because people are wrong in thinking that TLB fills
> > have to be slow. There's a lot of complete garbage RISC machines where
> > the TLB fill took forever, because in the name of simplicity it would
> > stop the pipeline and often be done in SW.
> > 
> > The zero-cycle TLB fill is obviously a bit optimistic, but at the same
> > time it's not completely insane. TLB fills can be prefetched, and the
> > table walker can hit the cache, if you do them right. And Intel mostly
> > does.
> > 
> > So the normal full (non-global) TLB fill really is fairly cheap. It's
> > been optimized for, and the TLB gets re-filled fairly efficiently. I
> > suspect that it's really the case that doing more than just a couple
> > of single-tlb flushes is a complete waste of time: the flushing takes
> > longer than re-filling the TLB well.
> > 
> 
> I expect I'll do another revision of the series after 4.2-rc1 as it's way
> too close to 4.1's release. When that happens, I'll drop patch 4 and leave
> just the full non-global flush patch. In the event there is an architecture
> that really cares about the refill cost or we find that there is a corner
> case where the TLB refill hurts then patch 4 will be in the mail archives
> to consider for rebase and testing.
> 

To be clear I meant patch 4 from v6 of the series will be dropped. In that
series, patch 2 does a full non-global flush and patch 4 does the per-pfn
tracking with multiple single page frame flushes.

-- 
Mel Gorman
SUSE Labs

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
	Minchan Kim <minchan@kernel.org>,
	Andi Kleen <andi@firstfloor.org>, H Peter Anvin <hpa@zytor.com>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/3] TLB flush multiple pages per IPI v5
Date: Tue, 9 Jun 2015 23:35:09 +0100	[thread overview]
Message-ID: <20150609223509.GX26425@suse.de> (raw)
In-Reply-To: <20150609223203.GW26425@suse.de>

On Tue, Jun 09, 2015 at 11:32:03PM +0100, Mel Gorman wrote:
> On Tue, Jun 09, 2015 at 02:54:01PM -0700, Linus Torvalds wrote:
> > On Tue, Jun 9, 2015 at 2:14 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> > >
> > > The 0 cycle TLB miss was also interesting.  It goes back up to something
> > > reasonable if I put the mb()/mfence's back.
> > 
> > So I've said it before, and I'll say it again: Intel does really well
> > on TLB fills.
> > 
> > The reason is partly historical, with Win95 doing a ton of TLB
> > invalidation (I think every single GDI call ended up invalidating the
> > TLB, so under some important Windows benchmarks of the time, you
> > literally had a TLB flush every 10k instructions!).
> > 
> > But partly it is because people are wrong in thinking that TLB fills
> > have to be slow. There's a lot of complete garbage RISC machines where
> > the TLB fill took forever, because in the name of simplicity it would
> > stop the pipeline and often be done in SW.
> > 
> > The zero-cycle TLB fill is obviously a bit optimistic, but at the same
> > time it's not completely insane. TLB fills can be prefetched, and the
> > table walker can hit the cache, if you do them right. And Intel mostly
> > does.
> > 
> > So the normal full (non-global) TLB fill really is fairly cheap. It's
> > been optimized for, and the TLB gets re-filled fairly efficiently. I
> > suspect that it's really the case that doing more than just a couple
> > of single-tlb flushes is a complete waste of time: the flushing takes
> > longer than re-filling the TLB well.
> > 
> 
> I expect I'll do another revision of the series after 4.2-rc1 as it's way
> too close to 4.1's release. When that happens, I'll drop patch 4 and leave
> just the full non-global flush patch. In the event there is an architecture
> that really cares about the refill cost or we find that there is a corner
> case where the TLB refill hurts then patch 4 will be in the mail archives
> to consider for rebase and testing.
> 

To be clear I meant patch 4 from v6 of the series will be dropped. In that
series, patch 2 does a full non-global flush and patch 4 does the per-pfn
tracking with multiple single page frame flushes.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2015-06-09 22:35 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 12:50 [PATCH 0/3] TLB flush multiple pages per IPI v5 Mel Gorman
2015-06-08 12:50 ` Mel Gorman
2015-06-08 12:50 ` [PATCH 1/3] x86, mm: Trace when an IPI is about to be sent Mel Gorman
2015-06-08 12:50   ` Mel Gorman
2015-06-08 12:50 ` [PATCH 2/3] mm: Send one IPI per CPU to TLB flush multiple pages that were recently unmapped Mel Gorman
2015-06-08 12:50   ` Mel Gorman
2015-06-08 22:38   ` Andrew Morton
2015-06-08 22:38     ` Andrew Morton
2015-06-09 11:07     ` Mel Gorman
2015-06-09 11:07       ` Mel Gorman
2015-06-08 12:50 ` [PATCH 3/3] mm: Defer flush of writable TLB entries Mel Gorman
2015-06-08 12:50   ` Mel Gorman
2015-06-08 17:45 ` [PATCH 0/3] TLB flush multiple pages per IPI v5 Ingo Molnar
2015-06-08 17:45   ` Ingo Molnar
2015-06-08 18:21   ` Dave Hansen
2015-06-08 18:21     ` Dave Hansen
2015-06-08 19:52     ` Ingo Molnar
2015-06-08 19:52       ` Ingo Molnar
2015-06-08 20:03       ` Ingo Molnar
2015-06-08 20:03         ` Ingo Molnar
2015-06-08 21:07       ` Dave Hansen
2015-06-08 21:07         ` Dave Hansen
2015-06-08 21:50         ` Ingo Molnar
2015-06-08 21:50           ` Ingo Molnar
2015-06-09  8:47   ` Mel Gorman
2015-06-09  8:47     ` Mel Gorman
2015-06-09 10:32     ` Ingo Molnar
2015-06-09 10:32       ` Ingo Molnar
2015-06-09 11:20       ` Mel Gorman
2015-06-09 11:20         ` Mel Gorman
2015-06-09 12:43         ` Ingo Molnar
2015-06-09 12:43           ` Ingo Molnar
2015-06-09 13:05           ` Mel Gorman
2015-06-09 13:05             ` Mel Gorman
2015-06-10  8:51             ` Ingo Molnar
2015-06-10  8:51               ` Ingo Molnar
2015-06-10  9:08               ` Ingo Molnar
2015-06-10  9:08                 ` Ingo Molnar
2015-06-10 10:15                 ` Mel Gorman
2015-06-10 10:15                   ` Mel Gorman
2015-06-11 15:26                   ` Ingo Molnar
2015-06-11 15:26                     ` Ingo Molnar
2015-06-10  9:19               ` Mel Gorman
2015-06-10  9:19                 ` Mel Gorman
2015-06-09 15:34           ` Dave Hansen
2015-06-09 15:34             ` Dave Hansen
2015-06-09 16:49             ` Dave Hansen
2015-06-09 16:49               ` Dave Hansen
2015-06-09 21:14               ` Dave Hansen
2015-06-09 21:14                 ` Dave Hansen
2015-06-09 21:54                 ` Linus Torvalds
2015-06-09 21:54                   ` Linus Torvalds
2015-06-09 22:32                   ` Mel Gorman
2015-06-09 22:32                     ` Mel Gorman
2015-06-09 22:35                     ` Mel Gorman [this message]
2015-06-09 22:35                       ` Mel Gorman
2015-06-10 13:13                   ` Andi Kleen
2015-06-10 13:13                     ` Andi Kleen
2015-06-10 16:17                     ` Linus Torvalds
2015-06-10 16:17                       ` Linus Torvalds
2015-06-10 16:42                       ` Linus Torvalds
2015-06-10 16:42                         ` Linus Torvalds
2015-06-10 17:24                         ` Mel Gorman
2015-06-10 17:24                           ` Mel Gorman
2015-06-10 17:31                           ` Linus Torvalds
2015-06-10 17:31                             ` Linus Torvalds
2015-06-10 18:08                         ` Josh Boyer
2015-06-10 18:08                           ` Josh Boyer
2015-06-10 17:07                       ` Mel Gorman
2015-06-10 17:07                         ` Mel Gorman
2015-06-21 20:22             ` Kirill A. Shutemov
2015-06-21 20:22               ` Kirill A. Shutemov
2015-06-25 11:48               ` Ingo Molnar
2015-06-25 11:48                 ` Ingo Molnar
2015-06-25 18:36                 ` Linus Torvalds
2015-06-25 19:15                   ` Vlastimil Babka
2015-06-25 19:15                     ` Vlastimil Babka
2015-06-25 22:04                     ` Linus Torvalds
2015-06-25 22:04                       ` Linus Torvalds
2015-06-25 18:46                 ` Dave Hansen
2015-06-25 18:46                   ` Dave Hansen
2015-06-26  9:08                   ` Ingo Molnar
2015-06-26  9:08                     ` Ingo Molnar

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=20150609223509.GX26425@suse.de \
    --to=mgorman@suse.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=mingo@kernel.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --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 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.