[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FBE4DB3.3070700@zytor.com>
Date: Thu, 24 May 2012 08:03:15 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Alex Shi <alex.shi@...el.com>
CC: Arjan van de Ven <arjan@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Lutomirski <luto@....edu>,
Jan Beulich <JBeulich@...e.com>, borislav.petkov@....com,
arnd@...db.de, akinobu.mita@...il.com, eric.dumazet@...il.com,
fweisbec@...il.com, rostedt@...dmis.org, hughd@...gle.com,
jeremy@...p.org, len.brown@...el.com, tony.luck@...el.com,
yongjie.ren@...el.com, kamezawa.hiroyu@...fujitsu.com,
seto.hidetoshi@...fujitsu.com, penberg@...nel.org,
yinghai@...nel.org, tglx@...utronix.de, akpm@...ux-foundation.org,
ak@...ux.intel.com, avi@...hat.com, dhowells@...hat.com,
mingo@...hat.com, riel@...hat.com, cpw@....com, steiner@....com,
linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
"asit.k.mallick@...el.com" <asit.k.mallick@...el.com>
Subject: Re: [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings
of SMT
On 05/24/2012 07:32 AM, Alex Shi wrote:
>>
>> the TLB pool is shared as physical resource (dynamic or static, that
>> depends), but each tlb entry will be tagged for which of the two HT
>> pairs it's for, and on a logical level, they are completely separate as
>> a result (as they should be)
>
> But, why just flush part of SMT doesn't crash kernel on many benchmarks
> testing? Does it means flush tlb without PCID (doesn't enable in current
> kernel) will flush both of 'TLB pool'?
>
> Oh, lots of questions of the TLB pool details. :) Could you like share
> the URL of related documents?
>
Hang on here... there is a huge difference between what a particular CPU
implementation does and what is architecturally guaranteed.
Both wearing my Linux x86 maintainer hat, and wearing my Intel employee
hat, I want to categorically state that Linux cannot rely on behavior
that isn't architecturally guaranteed. Unless we can get an
architectural guarantee that this elision is safe, it cannot go in. It
doesn't work the other way -- the burden of proof is to prove that the
change is safe, not that the change cannot be proven unsafe.
-hpa
--
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