From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (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 EDC20433CB for ; Mon, 6 Jan 2025 14:52:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736175181; cv=none; b=XAnv0RheztYPBkfkkHm7EIGUSO9z5d1/nqwo+56S2s9ae25qU65nNoGrw81MiM5GuZyHgf4uqJonIdkNv+go7bGES9yevsS7en68nosldbWSRz2MaYQmbuFt2P9E0JU8jdVereuQQueOHrdxqWacLdEw5ff3oJjPpy5XzNM+YnU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736175181; c=relaxed/simple; bh=PESAeVV02YdV6XkpF83bOgSQ72Aiy3aku8l/PeLQyIY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=KQ4xmvhFxEcPSiuqq2xOu0rUYt3gWuT7Ed898ySehtH86HlMBnqBYBRWaz5OEv0FBXSzpuDK15nrjD8oEMVbeE6e/d7BUeoOTmt2l8wFdbm55l2ARLx0Qs6M1J8RDhkgDIeQ3yqPzQmAQGtiM8KfF8qSZqe8UBbPB4nahrFxWr0= 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=OCfGZjcR; arc=none smtp.client-ip=209.85.218.53 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="OCfGZjcR" Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-aaf6b1a5f2bso1085110466b.1 for ; Mon, 06 Jan 2025 06:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736175175; x=1736779975; 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=D3lm+rr40xG7Vmc6rpPCsgkUiTEzw9Bvx3oilUcqvzM=; b=OCfGZjcRFBTPQFuI73vtlpCZ7KY3cso7ZBJU0WLTjSR8iwnN4rBV2t2LBe4096XHIZ 4C9S8ioyMA8vQd5Fw/PbRe0SZnReuxUWACIBOfppkTQtlXN5F8pMUK9MMkLUOT2bkVpA KrOblfA09aM9AtfKE+4MiDSeakSo82ErFqvtDByudBY3iFQVAeqC88nyKhgbboN1ncJ7 fkN1BGvuPPaPSxEBn4+xRekRaMI0SBVHgXKPf1S2zXmEEm4JlMjl8HsT0bMZpd2UwBe9 CsINMVLARZwL0ZJaOXjoc3HhHA7wfkdaDIkBrZivK2V2ZMyRFF/JvTTQlhWsyqMsHQet q2yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736175175; x=1736779975; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=D3lm+rr40xG7Vmc6rpPCsgkUiTEzw9Bvx3oilUcqvzM=; b=Zepwj4VstIdiYR+NJf1oek5GF5N34bCWOzK2+KUbQ250Bif8Nci7Zk0eRrt76ZJq9W 7YhGM28k6lRZddOtdS1z/aSXI4U+Q2+aLGkfEunoHM7jqBQJk2pePMyb4VZzO60lr4N5 oIhr6FFDEEJhbNCuvE0uVgKXq/FBJjsKZNG/vbgXgSvMuj9bCVfwyWsmONA+r/ZlLP53 NiO9jgWKAnRvEPANqZHzb7Rsj1W+J7lJyK/xsfskoaEv8pndUgd148yKWbNWHABPbY5C Nvq3as5A7YETuslbEf102k9fp6DHznlQto89bjFvbeAof2pNKPhtpaywYiKw166lip1/ 96Dg== X-Forwarded-Encrypted: i=1; AJvYcCUEDfag6OsszziQydzvK4i7jeyqxGmB5YIHdGIKcRN1mc8ENl5O0tjb0jfrDPhuicYjyUyfagm174O1d58=@vger.kernel.org X-Gm-Message-State: AOJu0YzKOrC+4It9wad76jUE5KYVQzra5tQA5mrpUbV1ymP40P8VtAVo QG3HS/EkyKigxWfcF3fFTcxu1boQz0nAgY3hMfWjKC0hDjpFknG9 X-Gm-Gg: ASbGncuoK2v3qM5VEIaGi+74wK0k193A6JptYG3S1/AimLqKhgDQovSnAC/Sy5EGwti 7F66vMAM+NR2sOEp4YsjEjEChBCh4rkxULuA+NwSyP7ussvf/a9WdTgER39c5vqJ0IJJ9Ubfu2m B6ffwpJvr6DfqKo0sKvC0BJZvxohW9WW3stLeJzNDm7UHqZ3BdcC/dGpeKyPeyTHhMYJFNwpatf YHy8/3H/fVgLXrWaQ/mnWB6gAlr6emQiTLjm+Qb8jJXW6Lq4jRP0fBO+EYQv67E3hM9mUf4Qw== X-Google-Smtp-Source: AGHT+IGMXgi7aAKrku0Ih1TYL4Oi5+9RORRRPw9nF07X7DXEI8lbVHj5AaDQfryV4t3MKdcXCS4ovA== X-Received: by 2002:a17:907:7fa1:b0:aab:8311:951f with SMTP id a640c23a62f3a-aac3349a9aamr5290769066b.6.1736175174842; Mon, 06 Jan 2025 06:52:54 -0800 (PST) Received: from smtpclient.apple ([132.69.243.32]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0f01608fsm2249856966b.150.2025.01.06.06.52.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2025 06:52:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii 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 \(3826.300.87.4.3\)) Subject: Re: [PATCH 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes From: Nadav Amit In-Reply-To: <20241230175550.4046587-10-riel@surriel.com> Date: Mon, 6 Jan 2025 16:52:41 +0200 Cc: the arch/x86 maintainers , Linux Kernel Mailing List , kernel-team@meta.com, Dave Hansen , luto@kernel.org, peterz@infradead.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrew Morton , zhengqi.arch@bytedance.com, "open list:MEMORY MANAGEMENT" Content-Transfer-Encoding: 7bit Message-Id: <6A40E0A3-CF69-481B-92D1-F86581DC3441@gmail.com> References: <20241230175550.4046587-1-riel@surriel.com> <20241230175550.4046587-10-riel@surriel.com> To: Rik van Riel X-Mailer: Apple Mail (2.3826.300.87.4.3) > On 30 Dec 2024, at 19:53, Rik van Riel wrote: > > +/* > + * 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: >= 4 active threads > + * 1/2 full: >= 8 active threads > + * 3/4 full: >= 16 active threads > + * 7/8 full: >= 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. > + */ > +#define HALFFULL_THRESHOLD 8 > +static bool meets_broadcast_asid_threshold(struct mm_struct *mm) > +{ > + int avail = broadcast_asid_available; > + int threshold = HALFFULL_THRESHOLD; > + > + if (!avail) > + return false; > + > + if (avail > MAX_ASID_AVAILABLE * 3 / 4) { > + threshold = HALFFULL_THRESHOLD / 4; > + } else if (avail > MAX_ASID_AVAILABLE / 2) { > + threshold = HALFFULL_THRESHOLD / 2; > + } else if (avail < MAX_ASID_AVAILABLE / 3) { > + do { > + avail *= 2; > + threshold *= 2; > + } while ((avail + threshold) < MAX_ASID_AVAILABLE / 2); > + } > + > + return mm_active_cpus_exceeds(mm, threshold); > +} Rik, I thought about it further and I am not sure this approach is so great. It reminds me the technique of eating chocolate forever: each day eat half of the previous day. It works in theory, but less in practice. IOW, I mean it seems likely that early processes would get and hog all broadcast ASIDs. It seems necessary to be able to revoke broadcast ASIDs, although I understand it can be complicated. Do you have any other resource in mind that Linux manages in a similar way (avoids revoking)?