[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190513113006.GP2623@hirez.programming.kicks-ass.net>
Date: Mon, 13 May 2019 13:30:06 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Nadav Amit <namit@...are.com>
Cc: Yang Shi <yang.shi@...ux.alibaba.com>,
"jstancek@...hat.com" <jstancek@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>,
Nick Piggin <npiggin@...il.com>,
Minchan Kim <minchan@...nel.org>, Mel Gorman <mgorman@...e.de>,
Will Deacon <will.deacon@....com>
Subject: Re: [PATCH] mm: mmu_gather: remove __tlb_reset_range() for force
flush
On Mon, May 13, 2019 at 09:11:38AM +0000, Nadav Amit wrote:
> BTW: sometimes you don’t see the effect of these full TLB flushes as much in
> VMs. I encountered a strange phenomenon at the time - INVLPG for an
> arbitrary page cause my Haswell machine flush the entire TLB, when the
> INVLPG was issued inside a VM. It took me quite some time to analyze this
> problem. Eventually Intel told me that’s part of what is called “page
> fracturing” - if the host uses 4k pages in the EPT, they (usually) need to
> flush the entire TLB for any INVLPG. That’s happens since they don’t know
> the size of the flushed page.
Cute... if only they'd given us an interface to tell them... :-)
Powered by blists - more mailing lists