[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83b019e2-1b84-491a-b0b9-beb02e45d80c@intel.com>
Date: Thu, 7 Mar 2024 07:29:34 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Yosry Ahmed <yosryahmed@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, x86@...nel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/3] x86/mm: make sure LAM is up-to-date during
context switching
On 3/7/24 05:39, Yosry Ahmed wrote:
> - /*
> - * Read the tlb_gen to check whether a flush is needed.
> - * If the TLB is up to date, just use it.
> - * The barrier synchronizes with the tlb_gen increment in
> - * the TLB shootdown code.
> - */
> - smp_mb();
> - next_tlb_gen = atomic64_read(&next->context.tlb_gen);
> - if (this_cpu_read(cpu_tlbstate.ctxs[prev_asid].tlb_gen) ==
> - next_tlb_gen)
> + if (!need_flush && !need_lam_update)
> return;
Instead of all this new complexity, why not just inc_mm_tlb_gen() at the
site where LAM is enabled? That should signal to any CPU thread that
its TLB is out of date and it needs to do a full CR3 reload.
Also, have you been able to actually catch this scenario in practice?
Considering how fun this code path is, a little effort at an actual
reproduction would be really appreciated.
Powered by blists - more mailing lists