From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACD542C027C for ; Tue, 16 Jun 2026 13:53:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781618021; cv=none; b=eZwlCbZwzGKO9lco+epmpbVuQfRb+t7DcIyMw3bmA7il9q5HirwySz970sEVl4Af4nmvBKBSEM9RGkzbr5DaKYCEH0fSKeMVkR3KES1OaM2vJSfl7cid6uwJMd7uRmOErA3EgUy2wRQDmqhTiSBGhNGwZOAB1SOraLO0qeuulP4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781618021; c=relaxed/simple; bh=jvocjogLdcw0QcfrmlxxGRwqA1/i1u2e4qYl2PII7x0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=i9Hcdecc7peZWAdubUVg6IaEWRfVMFs7rUNfNX1od3rY05mr17k9aX2F9zMiV9S6x+IyvwYjv/+/XAARUzwPY/d2LAl2akYrPOf0UnNoo5T5IJRy1k4zFTUgFOtJpBlp1vUqsFjlagQDe/ExKPPik+35cWgnIWpOJxnnpk22F1s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FmUJ/72P; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FmUJ/72P" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-45ef6565cfdso2164484f8f.0 for ; Tue, 16 Jun 2026 06:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781618018; x=1782222818; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=CwQutEunRqiQlU/ABJ1KNMUiTySBlQ+fPGjvSLq1PHs=; b=FmUJ/72P6zVO1Ws8RepLmJFB8uayR1iDXvA4ycBUIhQOgWCUdntlX5lJqtj49odBp1 jWkDUEGT4TX9pmawCXa7zacS8DDoHecse503J1JSxx+ScB3FLT09UaepBOQP0tfI9lbV 3Ke71ojyct3xWGSb4/2SshRnXZL62Na3JImGPy62OkjKHpCCnK/cDXouP5Q11ZDLlvKF i6chLR1QUDcJ8KVYUPEXdWXJRh5fp4pJ8M4NjVMluUuROV9EiWq3icbq4txQEpvIWEyo hmutZBAUxKhAomsLUEtgBhwFexWi4CPsmgvBNQvArwY6UD7EwWWiEGX73QHezfqUYdMB 5RsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781618018; x=1782222818; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=CwQutEunRqiQlU/ABJ1KNMUiTySBlQ+fPGjvSLq1PHs=; b=TPOc51MVQK8OBVE4GP+tbyQ/3jSqcKOU45SA5Y6Z+BjUbZv3hOQIAbcCuggMWMHq31 A8slpvNtnsCldntCSIV2kTR50c3j2qG17XHh3hLE17iADHozti5gch1iz9RnESJM54/X ax19+rL7SpwLlA8uDCyGgss7XFGY+HWGBoYZOFYSKJJiWTzjlH9QKssoBtY9W9f71wTB 5G24EdBML5m/ZLNXd//Hu6dabEY6jT5kbxCoEF3xgSp91cxozKlAYzBppRe/H76o1HZd b8DfIdiggslJq36fACATLtVwC+Th59ucCbbOe7PrjST+4hDpMa6eNkB76/yQWs1QvRYr WBMQ== X-Forwarded-Encrypted: i=1; AFNElJ+YxvDDXO9PzKOySn7kVpkzsBpD/JXAmryAPmQmHv20lB/WjeRJjMvfMDbRFCpBVZw8/QWSSMPIWAAGrog=@vger.kernel.org X-Gm-Message-State: AOJu0YzQXRHevbqjmCh0CR0vp6Yi53grLm47B6Fzrz4XH/Ws0c/hM3eg cAZ/ZoqOmc9rVaYhJsxSrhknUYO9I0mFrmOtGQWO5gAl56CQWra8P9gQN+HemNwH X-Gm-Gg: Acq92OGXnd/vO+T3lFe4vy4+2sjS0gJwzuS9KnMZwe0Iyk6/5S9m8lSidO/zJsKpTEG qn03V/nrJYZjDmNlqj034MDpA8KoGC+xC2xo2fq1RsNd/p1GNT0zPPYePCAHz+FJZkAZXEOQTOt Lyx4qdJekWq/Sq27VoRsToZApfCftWFkiS9DoRBdTDGmghcsxBE19vyHVuZrOeBzoYPwzabOIMc /6fQkhq0927M3NyhvMfXq6HHrJeb736+xoYgOynporTt6g49wx4Oi8JwZZo8TJ8UmXMzY9s93QL v2c9D2rK+JWacfchYPS6aPNLGwX+jhCd05XZsxt85q1RQMU96vfltWe2uXKA5pdcbe0Gsr+Ktlm 0qTa4VIJPK/IjODnKBK4H6FsUGrUS+cowUvtoMtErmm9wAzrtGsNWU/pWM0YcUfFIiSXNitRzSB V9rkwjFDy4/JS4ZHfcdWKeim+KxTGcPga/Usgykcfo/uCrhbQ4kGxDrW0a5Cit X-Received: by 2002:a5d:5d06:0:b0:461:a161:b625 with SMTP id ffacd0b85a97d-461a161b669mr6036915f8f.17.1781618017901; Tue, 16 Jun 2026 06:53:37 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f20e77asm47118776f8f.0.2026.06.16.06.53.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 06:53:37 -0700 (PDT) Date: Tue, 16 Jun 2026 14:53:34 +0100 From: David Laight To: Peter Zijlstra Cc: "H. Peter Anvin" , 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: <20260616145334.693c043a@pumpkin> In-Reply-To: <20260616082814.GQ48970@noisy.programming.kicks-ass.net> References: <20260613085919.GF42921@noisy.programming.kicks-ass.net> <203E61B7-290F-4F87-860F-B352D0072703@zytor.com> <20260616082814.GQ48970@noisy.programming.kicks-ass.net> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Tue, 16 Jun 2026 10:28:14 +0200 Peter Zijlstra wrote: > 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. Basically you can't win. I was looking at why a patch didn't give the expected performance gain on a different base kernel build. It seems to depend on whether the function (actually strlen) was aligned to an odd or even 16 byte boundary. If aligned to an even boundary the loop inside the function crossed a 'significant' boundary and the code ran measurably slower. If you start aligning loop tops and labels in general you probably lose due to code bloat. (Here the loop didn't need aligning, it just needed not to contain the relevant boundary.) In this case the extra padding will change the alignment of everything that follows - and some of those might make a difference as well. You'd need to add extra code further down the function to keep the size the same (and hope the compiler keeps the functions in the same order). David > > 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 >