From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 801093E5566 for ; Thu, 4 Jun 2026 21:11:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780607496; cv=none; b=HzXMyOpC8ZZnIPyEPjeXLsj6MI8AbG6eA+O+eFy6hinUMjBGk2OG7ykhi9CKURxbW3Q7MoFduSvAwa0t+2ofMAFShsXA1DsdO3/CYo+B/mg8dh5cI0wH19ceXNTIIv00DhPTr+o02de0SJ0Kia5l4tco72O3iYvyBSi2gTbO/KA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780607496; c=relaxed/simple; bh=Vh5paShl7qSfTblTqEVMQvJWuChAUW1W+b/fomMB7Bg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=A5M/jRuyucRG1GnGGVeU+rQvIuDRKhha4V4n0gFJb7pw8xC5zyv3DZyvtgDCqXhnKAiRAF2ubMBnScFqLmjAINW+p1O4rDReNbK3G5HAo0TgL+hLw+0FZTgmyW9YrpS5OxrwYJonZo8Ygjvc2NvwFOiQ4s/FGKC0Z+bz86RUoSM= 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=mr00Udpt; arc=none smtp.client-ip=209.85.128.46 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="mr00Udpt" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-490b4a8e28bso10372655e9.1 for ; Thu, 04 Jun 2026 14:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780607492; x=1781212292; 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=Vh5paShl7qSfTblTqEVMQvJWuChAUW1W+b/fomMB7Bg=; b=mr00Udpt2Y9Gfa7p9C3hpkGWGtA+VmygHEUS0FOWkmK0czlNlBXdwqvn+E4DlMwPtW h0YWTtheVLHNgjrBNY81aF4AxeNY2I19vxHoFxouzEqiQ3wP66CO2Rg655eapBCBA3OI eEO+49PlDZwJMh/Cyynwx82MtZ4TCJBP7FHQwo5KL7sewN8aXRmNKlfvo0P12q5KUD3q Y+3VMVP5/0ZJL+S/vof/cMy2bqmm9YWydld7GG+uJu818uZkK07Ndy5jIqJfpn6Bf1JF J6Iz6zILfMFIOgfCTb1iWbUF4lLy7hXjLD53hbWdvMRYQrKC/pkoMsIV+No0AQDSeqgL YXUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780607492; x=1781212292; 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=Vh5paShl7qSfTblTqEVMQvJWuChAUW1W+b/fomMB7Bg=; b=XmcINRMHwYUIYLh0Lc3Oase4NYWCt+4D4NshzCmjmHojKcP03kDGBgyvEslFbcYdzI OCiVgDm4EuvVY4nJGiKoFf6ygEWvWeVVvjhy7pBpQt+2hjjDh+s7bz7z0jwOE+aL7+G2 XLxYX4ZUZkfhDAQYNTxamd4gxo7eHjD9t6dt3/n/c8N0a27VHf0aidiM4UhfG7uR+NJJ zeBVrbCyUphZuVfRHliqhgyuDcf4Lp9HyH7b1wN1D6eETi0eQA2F3wFtREX8cvx8gvKv tcqmzoocOkspkoNvZtczyEyPGGzph7z5g8iINZmH4ySYPoh34FWPUw+Kt8wVBKyaMThG 92MA== X-Forwarded-Encrypted: i=1; AFNElJ9UCNeSvCvm2fiHfkeqXR9+C/+CUyzPRgKdHg3KLafUpoO5g2D1boSM6KwCdUk3QtrJQsx8wBMGZz0bqY4=@vger.kernel.org X-Gm-Message-State: AOJu0YxM9CdGPST1kqJJ5QlqWXQinv0AhVWQgi6w3VYvO3nahm/lJT+2 XfAwhyrqtceJvj4TTefe+bGqPYhQKGsNT66ATggMjtGJg4Ncl1B+1ELaJZ9b1UAX X-Gm-Gg: Acq92OEN4W3PwRnrf1Q/Rc/dw7mHkbRYyOKW8WdAJgiE8ojVO5r/CeX6Y6GZMRE51p3 wLCrnywp/zFSQj+DEEXNGTzEqQNQqNMsXG49AY/UgZ9BWzsqDDW6wd4t9qVsvxzD3SBHZY+Y+F2 xdMSFvQJ974m+xHEmlk+UAmNVdnN+blxj9Mzh/+o581vJXXvjYFEpZsc2BA8Dr0S8w2a/DLWpdS +0rHBYJra/dqyohtCCAXk33PPhzuF/uWhGSKzhK1KN1dOQ+HTrBICMmnich8OX2KuSU5cpU/ASB nIo3DjllnnOqgk3mun4MvsXdM+c7/AzqMP/SZF9lP5D2uZGQP9krktXOHHZYRN2maq/wSHXYMGG 1ZKOA8ZcG+3wS+uIgUtfEHIz2Z2ID1LgWIu/Ogw4y1YXqIoFXJCCHRDxFf21STKb+rY1dmu/KdD yE0xBJHa9QogECIPkQsDjb4txMH26lq8lAeLmdceGyxFLVssGIlhXaONICCeBdbGdPerk= X-Received: by 2002:a05:600c:5397:b0:490:3d62:f5e1 with SMTP id 5b1f17b1804b1-490c25f138bmr3945605e9.22.1780607491424; Thu, 04 Jun 2026 14:11:31 -0700 (PDT) Received: from smtpclient.apple ([64.176.164.200]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490bc3fd502sm96690255e9.11.2026.06.04.14.11.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2026 14:11:30 -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.600.51.1.1\)) Subject: Re: [PATCH v6 10/12] x86/mm: Move flush_tlb_info back to the stack From: Nadav Amit In-Reply-To: Date: Fri, 5 Jun 2026 00:11:17 +0300 Cc: Chuyi Zhou , tglx@kernel.org, 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, bigeasy@linutronix.de, clrkwllms@kernel.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <7A89193C-45D6-4118-87D5-9DC08EBFC11D@gmail.com> References: <20260528151338.617843-1-zhouchuyi@bytedance.com> <20260528151338.617843-11-zhouchuyi@bytedance.com> To: Dave Hansen X-Mailer: Apple Mail (2.3864.600.51.1.1) > On 4 Jun 2026, at 23:54, Dave Hansen wrote: >=20 > On 5/28/26 08:13, 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. >=20 > You've basically (nicely) thrown down the gauntlet and told Nadav that > his patch or methodology is bad. PeterZ also acked it Nadav's = approach. Dave, why can=E2=80=99t we all be friends. :) I communicated with Zhou about this. Back when I made my original = changes - the ones Zhou is now editing =E2=80=94 I also wanted to keep flush_tlb_info = on the stack with alignment. But PeterZ reverted that [1], because in certain cases = (KASAN with probably some experimental Intel larger cache-line size) the = cache-line alignment made the stack grow too much and triggered warnings. That's what led us to move flush_tlb_info into a per-cpu struct = (preemption was disabled at that time, so there was no trade-off). Now that Zhou = claims that disabling the preemption is a pain-point, and therefore does not = want to set flush_tlb_info per-cpu, the solution we've landed on is to put it = back on the stack - avoiding the need for a single flush_tlb_info that = depends on preemption being disabled =E2=80=94 while limiting the alignment to 64 = bytes so the stack doesn't grow out of control. [1] = https://lore.kernel.org/all/tip-780e0106d468a2962b16b52fdf42898f2639e0a0@g= it.kernel.org/