From: Alex Shi <alex.shi@linaro.org>
To: Andy Lutomirski <luto@amacapital.net>
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>
Subject: Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT
Date: Wed, 6 Apr 2016 13:15:23 +0800 [thread overview]
Message-ID: <57049B6B.1010009@linaro.org> (raw)
In-Reply-To: <CALCETrVmAosQ3p5ZJDH20bt5nQXG4pG=1S+egkaP6EqgxsNw1w@mail.gmail.com>
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
>
prev parent reply other threads:[~2016-04-06 5:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 3:14 [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT Alex Shi
2016-04-06 4:47 ` Andy Lutomirski
2016-04-06 5:15 ` Alex Shi [this message]
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=57049B6B.1010009@linaro.org \
--to=alex.shi@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox