From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 DE7861339A4 for ; Sun, 22 Dec 2024 22:45:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734907556; cv=none; b=TjwV+ga2NkEYu72R1p+abDE9E9chA5YDfZ7eJG63ATZwESDnlDH+eiBJQRruYqy9rOAO8SDIOP56uAomH+zxxiI7T8h0hEx+WxV4XiyaILYQSrNMGiYWtMdIT1QNh/6HHVLEPGxZZfkpBBENlteKSKYF0R0126PMnnRZ2AY8dvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734907556; c=relaxed/simple; bh=IzJGHnzbPJ1zLzrR0TGQjVs4AGHhjYdYGJDsvv8PutE=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=qf62Pq1BXwosjfbFu0Hif8hk01Flw/wGnWnFlph30AWA4grAudYLw+mPTaVzufBGyiSZUZdNlL+JhzUc3neJW6KZW5Q8cpdvoZH05FT/gtadVarY1b7pwJziB6rfw4fBtGmcQUMJBfIyAsnPRjjggYmLn6UlJRxKQtR3B2IcGD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=shelob.surriel.com; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shelob.surriel.com Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tPUhX-000000006lk-3Ftu; Sun, 22 Dec 2024 17:45:31 -0500 Message-ID: <007f3f4f65f9a940106d80b37da977cf2af85a6a.camel@surriel.com> Subject: Re: [PATCH 07/10] x86,mm: enable broadcast TLB invalidation for multi-threaded processes From: Rik van Riel To: Peter Zijlstra 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 Date: Sun, 22 Dec 2024 17:45:31 -0500 In-Reply-To: <20241222113601.GX11133@noisy.programming.kicks-ass.net> References: <20241222040717.3096835-1-riel@surriel.com> <20241222040717.3096835-8-riel@surriel.com> <20241222113601.GX11133@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Sender: riel@surriel.com On Sun, 2024-12-22 at 12:36 +0100, Peter Zijlstra wrote: > On Sat, Dec 21, 2024 at 11:06:39PM -0500, Rik van Riel wrote: >=20 > > +/* > > + * Figure out whether to assign a broadcast (global) ASID to a > > process. > > + * We vary the threshold by how empty or full broadcast ASID space > > is. > > + * 1/4 full: >=3D 4 active threads > > + * 1/2 full: >=3D 8 active threads > > + * 3/4 full: >=3D 16 active threads > > + * 7/8 full: >=3D 32 active threads > > + * etc > > + * > > + * This way we should never exhaust the broadcast ASID space, even > > on very > > + * large systems, and the processes with the largest number of > > active > > + * threads should be able to use broadcast TLB invalidation. >=20 > I'm a little confused, at most we need one ASID per CPU, IIRC we have > something like 4k ASIDs (page-offset bits in the physical address > bits) > so for anything with less than 4K CPUs we're good, but with anything > having more CPUs we're up a creek irrespective of the above scheme, > no? We don't need to use broadcast TLB flushing for every process in the system. If a system with 8196 CPUs runs a few large processes (hundreds, or thousands of active CPUs), we want to ensure those use broadcast TLB flushing with INVLPGB. We don't really care if some random systemd helper task ends up being relegated to IPI TLB flushing. The code is meant to ensure that the tasks where INVLPGB will help the most are the most likely to be able to use it. --=20 All Rights Reversed.