[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150610131354.GO19417@two.firstfloor.org>
Date: Wed, 10 Jun 2015 15:13:54 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Hansen <dave.hansen@...el.com>,
Ingo Molnar <mingo@...nel.org>, Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Hugh Dickins <hughd@...gle.com>,
Minchan Kim <minchan@...nel.org>,
Andi Kleen <andi@...stfloor.org>,
H Peter Anvin <hpa@...or.com>, Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] TLB flush multiple pages per IPI v5
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@...el.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.
Assuming the page tables are cache-hot... And hot here does not mean
L3 cache, but higher. But a memory intensive workload can easily
violate that.
That's why I'm dubious of all these micro benchmarks. They won't be
clearing caches. They generate unrealistic conditions in the CPU
pipeline and overestimate the cost of the flushes.
The only good way to measure TLB costs is macro benchmarks.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists