From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 5921A2C3260 for ; Wed, 18 Mar 2026 20:24:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773865498; cv=none; b=nkGWL2xC+yjUM5r3mV+q9mMdOMVSuEgXFSUndBZ/AK7rajnBPS4SNF3Cz89j4AQcEZna4tnUp2IBhXfGlVbYSDSJHyt2xuBO2fLjixU5fbv5hnPnGej33ajPx7c1IzyEjh3lZLmvmlp8u8uQgjGWSz6a7LzkK4wTUFRpjVrFr+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773865498; c=relaxed/simple; bh=ckmAhfm4CZ33ZxxtwWcHR5Rqw6yRZJUnAu/Bi557y/E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=EKPvvyzEhsp3ELulEJRdYAx/Xx7xGjhHm5Amjnvwy72FLrzmAgbe2goi1JZC0b9K6ccIWUAQ8qNVl3pIrzvwwALtzYa2WG3Bdr9D0Sq7eGvy0Da/mdrI/m8e09Wo1jhOzn7a7qL/syQxLaaiAP7GOxpP7wBD57kIHPr8NMoVvSo= 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=cNoBG9/w; arc=none smtp.client-ip=209.85.221.42 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="cNoBG9/w" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-43b49819938so118062f8f.0 for ; Wed, 18 Mar 2026 13:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773865495; x=1774470295; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5VmHp6wFmhezHR6RqeiHtkf4vt1RmhgpqEXW58vz7Bk=; b=cNoBG9/wO/8ApZa+C8+CF68Y7unwWmHcBioDJHBB+giaK3xqDwh4eoCKLIBoPhWCOK WRBsI3xP9fCCUUVG37miQmHJEfRW/kGlIw0VV1WvW6jxjhZY/P3eU796WAYmrLtFaKT2 JtEVN16gt+wnmfphLCuXN/raDLEf4BBlSrpSi6W1V3g0B9Q9a6nhAD5/OGuGJBJ+t5jY E4j65+DlKnqMdur1XR1xUBxi9fHj2v+re3k+pZDFM4tsWMklndjc2QIJfw7H/h5oszgM S+DX7IY4bl2dzMK7pjxgu2LHFxDlOmy/cUTbUlgOEspIT8Ec34pj7bo+tWqaWqEa6YZw mFfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773865495; x=1774470295; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5VmHp6wFmhezHR6RqeiHtkf4vt1RmhgpqEXW58vz7Bk=; b=T+1Bb6parHCvQrEbe/GU5D3q+WU7FDOA/KVF4FJTxQ/YgKkrbDoFsIMrKnjGvMwHPM wpw03/XkStaIM08Cp+to0jsxIxogJx2arrA16yVL3fcRJxkR6oyT3ujhD9Fya6vH3lvH eUiGFADEeLa31OMVaNQ6latu72wnv+ZGsE8iaUy2Cqch5Wh3wMDvevmpqBGLuoYuJ2Lm tcY465EGlOVBW++iqN06e/A69fHMUUyQNEZIfwHjJKNdaOrLik/5Rhl+7MClSEJTWeqq hI+I0aqvqfN218EAKmhG/v9gNEOC5xVUQFt9YtZzAavyyg21acE473jaCjPW4ZpAWvqj ce/Q== X-Forwarded-Encrypted: i=1; AJvYcCV3g2RvxHiY6fsc73I/7+UAHMDwum89DbqMkGz28IMFmV8ICtKgnzDdhTui3r75N70NeE3aJIoNzl2ICnM=@vger.kernel.org X-Gm-Message-State: AOJu0YzFxPP2nWhVG0TtxJNYFIgsMv8WO5+LZjYIV1NlJx6u1SbtETXx MMbCbm0UpUcpU8zXxJstjyH6MmtsJ87keGu3MhKTtrEhrsjabMVJScek X-Gm-Gg: ATEYQzwIhfK/I4XALP6UWhQmllLb0qkYPklsZoznU+OQgVnniKom/7nMCZfmjsxUNY9 LVPIOrbRzEtnEqfeVoeoehXxhfJwZo3wD4jUUdLeVgVQRNkX3fjXspTF86eO2/PNH8sgZ4r77+R Ms4m3ZB3Js90Cos4rVFmBT70Mkw4WSwMiTihBBbZQr+z4+6GEkrnezlBvovbGIB7HlQQNZPAJMy AX98FEJlPR/CBJF6OIdeZiapBRLRapNiCMO3QkbLApoAlr6I14JSBbZLKxhPzoJk6u7rAHuRwdk KMb9A15zWcTdJ0emdADimMmOH/RzZN66eIAJXqLcn8ybItdN9CfTgpdTCly6334qtT3V41uqa7t lgU20aAPF+YRG6Eh+s/y7mCGdMVMChTTZwTD3ZJ73Tbuw9P4zuNZpCabIgoVeNW3+vS8qbr+DB3 hr2T1X6gAAMQ36WT9riaXvBcSw+Q3pJpSPdH3aRAlPmOotUbMMMKZQ7w== X-Received: by 2002:a05:6000:18a3:b0:439:ac6b:dd38 with SMTP id ffacd0b85a97d-43b527c90a0mr8941651f8f.31.1773865495280; Wed, 18 Mar 2026 13:24:55 -0700 (PDT) Received: from smtpclient.apple ([212.59.70.37]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b51892228sm11890149f8f.17.2026.03.18.13.24.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2026 13:24:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: [PATCH v3 10/12] x86/mm: Move flush_tlb_info back to the stack From: Nadav Amit In-Reply-To: <20260318172143.ICooJ3-U@linutronix.de> Date: Wed, 18 Mar 2026 22:24:41 +0200 Cc: Chuyi Zhou , tglx@linutronix.de, mingo@redhat.com, luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev, bp@alien8.de, dave.hansen@linux.intel.com, pbonzini@redhat.com, clrkwllms@kernel.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <44F4BED1-D09A-40B3-BB2B-E2AFB0AF8D0D@gmail.com> References: <20260318045638.1572777-1-zhouchuyi@bytedance.com> <20260318045638.1572777-11-zhouchuyi@bytedance.com> <20260318172143.ICooJ3-U@linutronix.de> To: Sebastian Andrzej Siewior X-Mailer: Apple Mail (2.3864.400.21) > On 18 Mar 2026, at 19:21, Sebastian Andrzej Siewior = wrote: >=20 > +Nadav, org post = https://lore.kernel.org/all/20260318045638.1572777-11-zhouchuyi@bytedance.= com/ >=20 > On 2026-03-18 12:56:36 [+0800], Chuyi Zhou wrote: >> Commit 3db6d5a5ecaf ("x86/mm/tlb: Remove 'struct flush_tlb_info' from = the >> stack") converted flush_tlb_info from stack variable to per-CPU = variable. >> This brought about a performance improvement of around 3% in extreme = test. >> However, it also required that all flush_tlb* operations keep = preemption >> disabled entirely to prevent concurrent modifications of = flush_tlb_info. >> flush_tlb* needs to send IPIs to remote CPUs and synchronously wait = for >> all remote CPUs to complete their local TLB flushes. The process = could >> take tens of milliseconds when interrupts are disabled or with a = large >> number of remote CPUs. > =E2=80=A6 > PeterZ wasn't too happy to reverse this. > The snippet below results in the following assembly: >=20 > | 0000000000001ab0 : > =E2=80=A6 > | 1ac9: 48 89 e5 mov %rsp,%rbp > | 1acc: 48 83 e4 c0 and = $0xffffffffffffffc0,%rsp > | 1ad0: 48 83 ec 40 sub $0x40,%rsp >=20 > so it would align it properly which should result in the same = cache-line > movement. I'm not sure about the virtual-to-physical translation of = the > variables as in TLB misses since here we have a virtual mapped stack = and > there we have virtual mapped per-CPU memory. >=20 > Here the below is my quick hack. Does this work, or still a now? I = have > no numbers so=E2=80=A6 >=20 > diff --git a/arch/x86/include/asm/tlbflush.h = b/arch/x86/include/asm/tlbflush.h > index 5a3cdc439e38d..4a7f40c7f939a 100644 > --- a/arch/x86/include/asm/tlbflush.h > +++ b/arch/x86/include/asm/tlbflush.h > @@ -227,7 +227,7 @@ struct flush_tlb_info { > u8 stride_shift; > u8 freed_tables; > u8 trim_cpumask; > -}; > +} __aligned(SMP_CACHE_BYTES); >=20 This would work, but you are likely to encounter the same problem PeterZ = hit when I did something similar: in some configurations SMP_CACHE_BYTES is = very large. See = https://lore.kernel.org/all/tip-780e0106d468a2962b16b52fdf42898f2639e0a0@g= it.kernel.org/ Maybe cap the alignment somehow? something like: #if SMP_CACHE_BYTES > 64 #define FLUSH_TLB_INFO_ALIGN 64 #else #define FLUSH_TLB_INFO_ALIGN SMP_CACHE_BYTES #endif And then use __aligned(FLUSH_TLB_INFO_ALIGN) ?