From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-100.ptr.blmpb.com (sg-1-100.ptr.blmpb.com [118.26.132.100]) (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 D166F1DF271 for ; Tue, 3 Mar 2026 03:21:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772508067; cv=none; b=kYV7XJPqxNN20GfnpC35YZlcij0obOcFrEcHq0ZUqTN2M68QaCPxVeQ4CTOHflbEhmZT4eEu+6rpvvFfILgj6PEtcQkcClQYkqqYhd6/RTdVaP+EstZmUp8U0g81VYwxB0JoqJ2Cm2JPXF29zPWde5VxXnLAoVIx6UKzX4km4Mw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772508067; c=relaxed/simple; bh=dq/ShTpI8HGgxRuS1gDQXXc65JyU/cJ7sSIQ5vbQf/I=; h=Message-Id:In-Reply-To:To:Mime-Version:Subject:Date:Content-Type: From:References:Cc; b=X7tlU6Vwt/2L/YCdeEY2SU1JgJieeHEyOll82n8OERwltCv/bsIFgHYZ0z4v7PX39S0Ks/gaQPiN4553xPuKN7E5r42WO/bevmk/GoRyV7V7l/NHjdHpjWsiqil1TOAPl/1vtEqEb4L+/c2QlrBMRECbSjzbKPMJHXm1xMhYIGQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=Ssn3hIea; arc=none smtp.client-ip=118.26.132.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="Ssn3hIea" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1772508053; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=20uclELOTsrmduNVttPvdumCNW2J+0fgpSEFELWPUrw=; b=Ssn3hIea68W+eGnSMl9kkWySUb9M1KjzCIh2bOEPDsnRtBGSmozI0uBrlHGdFKmwLONAof rbyoig3Ii2CxnXwIM0IpnXOrdYnD+Ia42UiCpOFuax18UwD3Gc12pV4FHUAsRcdKlb5mV6 5BnQCWjaHOL9lknztqJTHHdIQng29M7Z7gbrHLStGbzmdKgtPL5P6ICH+Vt5c/K0DySBO5 G2Pw9mj/JGKOc03pEQQPD7wMfUc+HhyL2wiC4GoSDFmGqnpc6Pdw+DVdJJFwkRByUj7X3T D3y4v/5sd/sYvcFO6sgcXFjlJbefg44fYBwZA+yWRQGeS3DlFYOCaLCgbJIWjw== Message-Id: <538ab199-4aa3-488a-b285-c88223c38c3e@bytedance.com> In-Reply-To: <20260302145848.GI1395266@noisy.programming.kicks-ass.net> X-Original-From: Chuyi Zhou To: "Peter Zijlstra" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2 10/12] x86/mm: Move flush_tlb_info back to the stack Date: Tue, 3 Mar 2026 11:20:33 +0800 User-Agent: Mozilla Thunderbird X-Lms-Return-Path: Content-Type: text/plain; charset=UTF-8 From: "Chuyi Zhou" References: <20260302075216.2170675-1-zhouchuyi@bytedance.com> <20260302075216.2170675-11-zhouchuyi@bytedance.com> <20260302145848.GI1395266@noisy.programming.kicks-ass.net> Cc: , , , , , , , , , , , Hi Peter =E5=9C=A8 2026/3/2 22:58, Peter Zijlstra =E5=86=99=E9=81=93: > On Mon, Mar 02, 2026 at 03:52:14PM +0800, Chuyi Zhou wrote: >> Commit 3db6d5a5ecaf ("x86/mm/tlb: Remove 'struct flush_tlb_info' from th= e >> stack") converted flush_tlb_info from stack variable to per-CPU variable= . >> This brought about a performance improvement of around 3% in extreme tes= t. >> 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. >> >> From the perspective of improving kernel real-time performance, this pa= tch >> reverts flush_tlb_info back to stack variables. This is a preparation fo= r >> enabling preemption during TLB flush in next patch. >=20 > This isn't properly justified. You've got to show that 'most' workloads > are not adversely affected by this. >=20 > Most people still swing towards performance most of the time. I will try to reproduce the microbenchmarks mentioned in Commit=20 3db6d5a5ecaf ("x86/mm/tlb: Remove 'struct flush_tlb_info' from the stack"). In addition, I will check whether there are suitable general memory=20 tests available in the mmtests framework. I will send the results afterwards. Thanks.