From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 B321E1BC9FF for ; Tue, 24 Dec 2024 18:13:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735064013; cv=none; b=QA/KwWw8Xx+rFh/pGt10FOPfZctiNm6FJHz3OLh1TmOYj7Zlp13bECCK1HsaV6C8RFb0eU2Y7wdxd4OUWw27/4vZbrKSp3ru+oeBBYhIBaCK8a/uhmSpwldZscePat1/iQMnX3i/ZLqaAW/izqhY7BRrQOXQ5I7MOXRkybRskGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735064013; c=relaxed/simple; bh=YJy3Wg2pRQIsLpdEKLuLHYUAWCfziyPuIbDqJW1JMaA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ca8KmPbe1ec2YNFw33H6Rc6zuKoP55I2pI0dNjsf/oEa2So3vzxijhZkHCqKjkMvYLOtVtmha3YVnm48kuSjA/l5cyWVTJhKWJqsqJ2RONYoHy9EyBcR15qG1vimx2Wa2Lfp014UHjxf6tYS2TqfHcm3pgE2vKEF2rc97+Wuyx0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (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=TooJTcSu; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (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="TooJTcSu" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=csCI5H1fI/Vhu2/qwDBTpBZFiD4v6dGpuRwIYbybNQ4=; b=TooJTcSus6qNvInyXFzCvKqBdf M0f5HjNfc64hEFq6reqpC28Nk5/MAXuVe89ERMqdUh3hZnbCzsdM9Jr/fPIEfKpOobJ25942td+6f NI7gORcVkZ4GNkR5nA87gAunD+Cs+1OKtflJns+uGKI4doP9Yxc5VFxQge7nGskJfPYKDIADW0WEZ xUJGwganaCW+nwaqr+qc/8ishQpAUqs3J51EHCEBxaSyOkTXAabF3sFThvYVdar+VyNTfTCq6D7cR HzE9FWDi9OOqQIoRXEiqe/MGomyHE+38ADv8uYvVfe4ExgRD3RWXsaSvK/Jda9az0Aw8VqEdNXzEm +UOZbE7w==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tQ9P3-00000004200-2Jjp; Tue, 24 Dec 2024 18:13:10 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id DC48A300478; Tue, 24 Dec 2024 19:13:08 +0100 (CET) Date: Tue, 24 Dec 2024 19:13:08 +0100 From: Peter Zijlstra To: Rik van Riel Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, dave.hansen@linux.intel.com, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org Subject: Re: [PATCH 04/10] x86,mm: use INVLPGB for kernel TLB flushes Message-ID: <20241224181308.GA17252@noisy.programming.kicks-ass.net> References: <20241222040717.3096835-1-riel@surriel.com> <20241222040717.3096835-5-riel@surriel.com> <20241222111606.GU11133@noisy.programming.kicks-ass.net> <86a2ca80d2be3a943566473ea156180abf3b2557.camel@surriel.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: <86a2ca80d2be3a943566473ea156180abf3b2557.camel@surriel.com> On Sun, Dec 22, 2024 at 10:12:56AM -0500, Rik van Riel wrote: > On Sun, 2024-12-22 at 12:16 +0100, Peter Zijlstra wrote: > > On Sat, Dec 21, 2024 at 11:06:36PM -0500, Rik van Riel wrote: > > > Use broadcast TLB invalidation for kernel addresses when available. > > > > > > +static void broadcast_kernel_range_flush(unsigned long start, > > > unsigned long end) > > > +{ > > > + unsigned long addr; > > > + unsigned long maxnr = boot_cpu_data.invlpgb_count_max; > > > + unsigned long threshold = tlb_single_page_flush_ceiling * > > > maxnr; > > > + > > > + /* > > > + * TLBSYNC only waits for flushes originating on the same > > > CPU. > > > + * Disabling migration allows us to wait on all flushes. > > > + */ > > > + migrate_disable(); > > > > So how expensive is all this? That is, I think I would feel better is > > this were preempt_disable(). > > Either should work. If preempt_disable() is cheaper, > I'm happy to use that. I'm not sure about cheaper -- but getting arbitrary scheduling delays in the middle of TLBi sounds like waaay to much 'fun'.