[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVmAosQ3p5ZJDH20bt5nQXG4pG=1S+egkaP6EqgxsNw1w@mail.gmail.com>
Date: Tue, 5 Apr 2016 21:47:23 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Alex Shi <alex.shi@...aro.org>
Cc: X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, Rik van Riel <riel@...hat.com>
Subject: Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT
On Apr 5, 2016 8:17 PM, "Alex Shi" <alex.shi@...aro.org> wrote:
>
> It seems Intel core still share the TLB pool, flush both of threads' TLB
> just cause a extra useless IPI and a extra flush. The extra flush will
> flush out TLB again which another thread just introduced.
> That's double waste.
Do you have a reference in both the SDM and the APM for this?
Do we have a guarantee that this serialized the front end such that
the non-targetted sibling won't execute an instruction that it decoded
from a stale translation?
This will conflict rather deeply with my PCID series, too.
--Andy
Powered by blists - more mailing lists