linux-kernel - Re: [PATCH 5/6] x86: mm: new tunable for single vs full TLB flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53594FB3.9050505@redhat.com>
Date:	Thu, 24 Apr 2014 13:53:55 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Dave Hansen <dave@...1.net>, Mel Gorman <mgorman@...e.de>
CC:	x86@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	akpm@...ux-foundation.org, kirill.shutemov@...ux.intel.com,
	ak@...ux.intel.com, alex.shi@...aro.org,
	dave.hansen@...ux.intel.com, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 5/6] x86: mm: new tunable for single vs full TLB flush

On 04/24/2014 01:25 PM, Dave Hansen wrote:
> On 04/24/2014 03:37 AM, Mel Gorman wrote:
>> On Mon, Apr 21, 2014 at 11:24:26AM -0700, Dave Hansen wrote:
>>> +This will cause us to do the global flush for more cases.
>>> +Lowering it to 0 will disable the use of the individual flushes.
>>> +Setting it to 1 is a very conservative setting and it should
>>> +never need to be 0 under normal circumstances.
>>> +
>>> +Despite the fact that a single individual flush on x86 is
>>> +guaranteed to flush a full 2MB, hugetlbfs always uses the full
>>> +flushes.  THP is treated exactly the same as normal memory.
>>> +
>>
>> You are the second person that told me this and I felt the manual was
>> unclear on this subject. I was told that it might be a documentation bug
>> but because this discussion was in a bar I completely failed to follow up
>> on it. Specifically this part in 4.10.2.3 caused me problems when I last
>> looked at the area.
> <snip>
>
> My understanding comes from "4.10.4.2 Recommended Invalidation":
>
> 	• If software modifies a paging-structure entry that identifies
> 	the final page frame for a page number (either a PTE or a
> 	paging-structure entry in which the PS flag is 1), it should
> 	execute INVLPG for any linear address with a page number whose
> 	translation uses that PTE. 2
>
> and especially the footnote:
>
> 	2. One execution of INVLPG is sufficient even for a page with
> 	size greater than 4 KBytes.
>
> I do agree that it's ambiguous at best.  I'll go see if anybody cares to
> update that bit.

I suspect that IF the TLB actually uses a 2MB entry for the
translation, a single INVLPG will work.

However, the CPU is free to cache the translations for a 2MB
region with a bunch of 4kB entries, if it wanted to, so in
the end we have no guarantee that an INVLPG will actually do
the right thing...

The same is definitely true for 1GB vs 2MB entries, with
some CPUs being capable of parsing page tables with 1GB
entries, but having no TLB entries for 1GB translations.
--
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/