Subject: Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT
To: Andy Lutomirski <luto@amacapital.net>
References: <1459912457-5630-1-git-send-email-alex.shi@linaro.org>
 <CALCETrVmAosQ3p5ZJDH20bt5nQXG4pG=1S+egkaP6EqgxsNw1w@mail.gmail.com>
Cc: X86 ML <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Rik van Riel <riel@redhat.com>
From: Alex Shi <alex.shi@linaro.org>
Message-ID: <57049B6B.1010009@linaro.org>
Date: Wed, 6 Apr 2016 13:15:23 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CALCETrVmAosQ3p5ZJDH20bt5nQXG4pG=1S+egkaP6EqgxsNw1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1020
Lines: 30


On 04/06/2016 12:47 PM, Andy Lutomirski wrote:
> On Apr 5, 2016 8:17 PM, "Alex Shi" <alex.shi@linaro.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?

No. as I said in the end of commit log. There are no any official
guarantee for this usage, but it seems working widely in Intel CPUs.

And the performance benefit is so tempted...
Is there Intel's guys like to dig it more? :)

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

Is your worrying an evidence for my guess? Otherwise the stale
instruction happens either before IPI coming in... :)
> 
> This will conflict rather deeply with my PCID series, too.
> 
> --Andy
>