Re: [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings of SMT

["H. Peter Anvin" <hpa@zytor.com>]

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