mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com,  dave.hansen@linux.intel.com,
	luto@kernel.org, tglx@linutronix.de, mingo@redhat.com,
		bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org
Subject: Re: [PATCH 09/10] x86/mm: enable AMD translation cache extensions
Date: Sun, 22 Dec 2024 10:37:01 -0500	[thread overview]
Message-ID: <5ae11e5ac6b278de9ad2ad2badbd5f010543d934.camel@surriel.com> (raw)
In-Reply-To: <20241222113811.GY11133@noisy.programming.kicks-ass.net>

On Sun, 2024-12-22 at 12:38 +0100, Peter Zijlstra wrote:
> On Sat, Dec 21, 2024 at 11:06:41PM -0500, Rik van Riel wrote:
> > With AMD TCE (translation cache extensions) only the intermediate
> > mappings
> 
> Only the leave mapings, as written this all don't make sense,

Check out page 513 of the AMD manual:

https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/40332.pdf

"Translation Cache Extension (TCE) Bit. Bit 15, read/write. 

Setting this bit to 1 changes how the INVLPG, INVLPGB, and INVPCID
instructions operate on TLB entries. When this bit is 0, these
instructions remove the target PTE from the TLB as well as all 
upper-level table entries that are cached in the TLB, whether or 
not they are associated with the target PTE. When this bit is set,
these instructions will remove the target PTE and only those 
upper-level entries that lead to the target PTE in the page table
hierarchy, leaving unrelated upper-level entries intact. This may
provide a performance benefit.

Page table management software must be written in a way that takes 
this behavior into account. Software that was written for a 
processor that does not cache upper-level table entries may result 
in stale entries being incorrectly used for translations when TCE 
is enabled. Software that is compatible with TCE mode will operate
in either mode.

For software using INVLPGB to broadcast TLB invalidations, the
invalidations are controlled by the EFER.TCE value on the processor
executing the INVLPGB instruction.

Before setting TCE, system software should verify that this feature
is supported by examining the feature flag CPUID Fn8000_0001_ECX[TCE].
See Section 3.3 “Processor Feature Identification,” on
page 71 for information on using the CPUID instruction"


This suggests that:
1) TCE does control the "don't make sense" behavior :)

2) Wait, does EFER.TCE need to be set on every CPU
   in the system?  Could a system run with TCE set
   on some CPUs, and cleared on another?!

It would be nice if somebody from AMD could chime in on
the latter, and ensure that this patch actually does
the right thing :)

I'll incorporate all the other feedback from you and
Borislav into the next version of the patch series!
Thank you for the feedback.

-- 
All Rights Reversed.

  reply	other threads:[~2024-12-22 15:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-22  4:06 [RFC PATCH 00/10] AMD broadcast TLB invalidation Rik van Riel
2024-12-22  4:06 ` [PATCH 01/10] Add X86_FEATURE_INVLPGB definition Rik van Riel
2024-12-22  4:06 ` [PATCH 02/10] x86,tlb: get INVLPGB count max from CPUID Rik van Riel
2024-12-22 11:46   ` Borislav Petkov
2024-12-22 14:39     ` Rik van Riel
2024-12-22  4:06 ` [PATCH 03/10] x86,mm: add INVLPGB support code Rik van Riel
2024-12-22 11:05   ` Peter Zijlstra
2024-12-22 21:24     ` Rik van Riel
2024-12-22  4:06 ` [PATCH 04/10] x86,mm: use INVLPGB for kernel TLB flushes Rik van Riel
2024-12-22 11:16   ` Peter Zijlstra
2024-12-22 15:12     ` Rik van Riel
2024-12-24 18:13       ` Peter Zijlstra
2024-12-22 11:47   ` Borislav Petkov
2024-12-22  4:06 ` [PATCH 05/10] x86,tlb: use INVLPGB in flush_tlb_all Rik van Riel
2024-12-22 11:17   ` Peter Zijlstra
2024-12-22  4:06 ` [PATCH 06/10] x86,mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2024-12-22 11:18   ` Peter Zijlstra
2024-12-22  4:06 ` [PATCH 07/10] x86,mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2024-12-22 11:36   ` Peter Zijlstra
2024-12-22 22:45     ` Rik van Riel
2024-12-22  4:06 ` [PATCH 08/10] x86,tlb: do targeted broadcast flushing from tlbbatch code Rik van Riel
2024-12-22  4:06 ` [PATCH 09/10] x86/mm: enable AMD translation cache extensions Rik van Riel
2024-12-22 11:38   ` Peter Zijlstra
2024-12-22 15:37     ` Rik van Riel [this message]
2024-12-24 18:25       ` Peter Zijlstra
2024-12-22  4:06 ` [PATCH 10/10] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2024-12-22 11:11 ` [RFC PATCH 00/10] AMD broadcast TLB invalidation Peter Zijlstra
2024-12-22 15:06   ` Rik van Riel

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=5ae11e5ac6b278de9ad2ad2badbd5f010543d934.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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

all inboxes | Powered by JetHome®