From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 B0B9D3E714D for ; Mon, 2 Mar 2026 14:59:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772463548; cv=none; b=VJ7h4EZ58pUwOZ6QQaJHk1+lgSZJZyKb78zKLH0xEe9ZwNT1uf5MfaKB9YFGFY7nCgOi2P18Fzs4TK5i4hRVVHY/ihL7HVNKsRCGBvTR45B+Ut2OGIFQVmT5ZiKN8SaR0iKB1cymjLmPDcyRSjP2xdp69/6WEXyUJmWjNlghIvU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772463548; c=relaxed/simple; bh=gtZqt3gs29L0crGt5c9nnFucOOVc6pmtR0VcUPEMeeg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DRNd0Y/2JaiuvaifDVBqC4kmjLXytYyoMSaFVumdaa9WNT8Va1lhJJbqA/3K1YmkkhPUPUBfJKthmKYYrdY3XqQOIkruvuQ3VDaazlXulmfcNVBFCPTZ1CcVlpds3UC6BOSE6/yMxoYB6BNoHndbupZ0GfiBbnoePJnyY5ABEyU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=MdNls3yl; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none 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="MdNls3yl" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=pxKxwRGpP3ckXEeDEN+x2pEI4xuW3cZrvdrqQRVcbNk=; b=MdNls3yl9UoWZUTNBaU0p9nVWB tlB5M5KH2q0O/Ke/maVzlR6x4AlxidLD4D+cbjmuxX433TmmGQc8/oxJi07kG+hKkIMTeucT6apx4 vgeCWXbrlPA+fUakhelovmkDso9YESZXYf7l9PjQTq2e02+QN1sjO4fdRgzhSr86VHWfX9G8fwSgA PlaCw6HBWnA4eIHXPKQQeQeZzGdj5H9T1GkAx4nLjjZHfYnZCnvBb/mYPUebq4H2ZRB409UJgZ2Mg pPVHEVlCVaru3sS4DFIr8RwcQXCnxFjga50Jf9okVPvD8mgNQwrlqXDu46Q8TXB1tML6Yil5H49wI xOvwvQLw==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vx4jR-00000000Mwv-1n2A; Mon, 02 Mar 2026 14:58:49 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 77B42300B40; Mon, 02 Mar 2026 15:58:48 +0100 (CET) Date: Mon, 2 Mar 2026 15:58:48 +0100 From: Peter Zijlstra To: Chuyi Zhou Cc: tglx@linutronix.de, mingo@redhat.com, luto@kernel.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 Subject: Re: [PATCH v2 10/12] x86/mm: Move flush_tlb_info back to the stack Message-ID: <20260302145848.GI1395266@noisy.programming.kicks-ass.net> References: <20260302075216.2170675-1-zhouchuyi@bytedance.com> <20260302075216.2170675-11-zhouchuyi@bytedance.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: <20260302075216.2170675-11-zhouchuyi@bytedance.com> On Mon, Mar 02, 2026 at 03:52:14PM +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. > > From the perspective of improving kernel real-time performance, this patch > reverts flush_tlb_info back to stack variables. This is a preparation for > enabling preemption during TLB flush in next patch. This isn't properly justified. You've got to show that 'most' workloads are not adversely affected by this. Most people still swing towards performance most of the time.