linux-kernel - [PATCH 0/2 v2] x86,tlb: context switch optimizations

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-next>] [day] [month] [year] [list]

Message-ID: <20241114152723.1294686-1-riel@surriel.com>
Date: Thu, 14 Nov 2024 10:26:15 -0500
From: Rik van Riel <riel@...riel.com>
To: linux-kernel@...r.kernel.org
Cc: dave.hansen@...ux.intel.com,
	luto@...nel.org,
	peterz@...radead.org,
	tglx@...utronix.de,
	mingo@...hat.com,
	bp@...en8.de,
	x86@...nel.org,
	kernel-team@...a.com,
	hpa@...or.com
Subject: [PATCH 0/2 v2] x86,tlb: context switch optimizations

While profiling switch_mm_irqs_off with several workloads,
it appears there are two hot spots that probably don't need
to be there.

The patch placing the mm_cpumask test inside the prev == next
branch behind CONFIG_DEBUG_VM got merged into x86/mm already,
so here are the other two.

The approach used in v2 to ensure the call to flush_mm_tlb_range()
from __text_poke() remains a noop is to clear the CPU from the
mm_cpumask of poke_mm. Fix suggested by Peter Zijlstra.

That way the only thing flush_mm_tlb_range() really ends up
doing is increment the tlb_gen, resulting in future users of
poke_mm flushing the TLB.