From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 601053B47CF for ; Tue, 16 Jun 2026 08:28:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781598506; cv=none; b=ooFRE54uZMJq+hO7Mu9J50jebswjiJT7GCHK4RBCgtrPbesNzY2WIK25iQEcmWdC6nfsaA1fQgG4ZEiVhaLNNarsszjLDZaWZijCf+jqqJ/GuQdrGGrkQHL0FVgZGm2snPns2JbFGdFnbpx0R5pzwLOXcoXELvYSnz17EXMKU1k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781598506; c=relaxed/simple; bh=/ctLO+XOhhME7IkzUrLEC0f4gqUqA1sv3uGMnz0/DBs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JDCL6z81SFTX2ac6ggXM7UYbcS4Qaga81wLuZ8ghjx8EzMMHpdACuqiFahg1rgFjEPRpSJ3QWkO09HUHf5xCd06ia96ANw7Lu05ZyJ0TnXSz9vSIkM+MzclFvFjpITgOFZwNA1nBXCGGaoKKFdPQLvLwvUUJitkHpkENaHO7tdA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=wNuczyGS; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="wNuczyGS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2ggcSCq/mVnwHYsMO5IDjU+3b2uGHqnVHoFM4qKmOTI=; b=wNuczyGS+cYEM8/3lH7GSoFx4U hrhjl5/0e9IagtcrF3bHG094URaboLV06WpNVMtAVrzuSmE8/dPcSXDxB7PIPvIcc4+mZJrplahkZ 1aaNbgj3QiJZAjI7+upzWip0FBNlH6kvTbYEwuVPXl9+H36EODUXKPojl9PZtAE9dKLSRPq20e18k +UyB3iyqXhswahIBmecmLLyh5/gBYn6CIrLu/VFkbqhFjRCqWN84RER3N3nQSSKKSV/BoT8NP51nU CFIG265IRYA3IQY5/BdCkCJWlwAmLK2TvqcM2y5tXHkhQTM3aHCDlEpzlwGMY73iU+JzFHzG4czP9 9TG3kl8g==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wZP9b-0000000AOjt-3Yk0; Tue, 16 Jun 2026 08:28:16 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 0BD0230036F; Tue, 16 Jun 2026 10:28:15 +0200 (CEST) Date: Tue, 16 Jun 2026 10:28:14 +0200 From: Peter Zijlstra To: "H. Peter Anvin" Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, Nathan Chancellor , Calvin Owens , Dave Hansen , torvalds@linux-foundation.org, x86-ML , LKML Subject: Re: 8aeb879baf12 - significant system call latency regression, bisected Message-ID: <20260616082814.GQ48970@noisy.programming.kicks-ass.net> References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Jun 13, 2026 at 06:50:24PM -0700, H. Peter Anvin wrote: > OK, I have, I believe root-caused this. > > It is a padding issue; removing the code changes __pfx_x64_sys_call to be > 32-byte aligned, with the result that x64_sys_call gets *mis*aligned. > > Reverting the patch but adding an alignment statement to x64_sys_call > re-introduces the performance regression. > > I am concerned because this could mean that the __pfx stubs add substantial > overhead elsewhere, unless this just happens to be a particularly sensitive > case... So what is the actual alignment requirement these days then? We're building the (x86_64) kernel with 16 byte function and 1 byte jump alignment. So ISTR the Intel I-fetch window was 16 bytes, so the above things would make sense. However, Gemini, or whatever AI sits in google search, is trying to tell me Intel moved to 32 byte I-fetch with Alderlake. That same thing is saying AMD switched to 32 byte I-fetch with Zen (1) and later. This all seems to suggest we do something like so, hmm? diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b9f5a4a3cc2a..65fff65271d0 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -329,7 +329,9 @@ config X86 select HAVE_ARCH_KCSAN if X86_64 select PROC_PID_ARCH_STATUS if PROC_FS select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX - select FUNCTION_ALIGNMENT_16B if X86_64 || X86_ALIGNMENT_16 + # AMD-Zen+ and Intel-Alderlake+ moved to 32 byte I-fetch + select FUNCTION_ALIGNMENT_32B if X86_64 + select FUNCTION_ALIGNMENT_16B if X86_ALIGNMENT_16 select FUNCTION_ALIGNMENT_4B imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE