From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 75ACD18B470; Mon, 24 Mar 2025 08:04:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742803498; cv=none; b=UwsiaRbUHEu/0fwmQDSunjEPu7/C5npCWB7PtwRo9tC+0CApuKy9mhfgPjZ+qM3TxgjlOGJ6zrLpns4pq9V9mruJ5m0FAMwAGYVFyw8XwyHxfg8kuyzC/GyWXKDNwE0+l1RoRaOjpMX4TsZTOygyCqiR11ya89wxTteW6qOEv6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742803498; c=relaxed/simple; bh=2gSLluaFzVDaLqnWsNk8sVoYQ+2ifhmEkiUog9vfzOk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cG3S9crPCTFVKvZ2Mm7IwuL2fTylTkaB5/iYpZHfzRkJjweMmHEa8Dx+f4/PRL/7nHNvR9+S0+dshnthnnporcsN6KxbBhnaz9mbdrZ0monf1mEhRl4kvoAO52ywuP1WGY+5A45PR4yGBDA1vzFB4KRFYU9Fydun34tE5gZgrQU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RGynYWlj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RGynYWlj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1451BC4CEDD; Mon, 24 Mar 2025 08:04:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742803497; bh=2gSLluaFzVDaLqnWsNk8sVoYQ+2ifhmEkiUog9vfzOk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RGynYWljYVwsjBkFfRfR2JqFmEpoDbpRvYy/VqSO977TnZaXU4Bqk5Oi73yGNsmzT 7pO8mPc/CiqmEsMhvsQzsbZXEOombY5TdnaCSfSfgApcR2oCoiIdWRKlh9mJtg5ndZ ZhzacUowUFkM878v9z5W7PQoaum7xVkkGN5wDtaipvu3OiXv/NaFWGjJs3UKPxQG/a 6FNJvUVt3Q+wKg15fZGoNsDTxCz9fewYvF3ESQyZ9R/w7TwDx4eZXjY5a53p4eeG71 gbuR5LjomfD8yWv/AN9/7d+wEf5Zwa6jOnexDlxYy9GM0qKEVF602UKdYGgL5RTJ5X Zpooy1FVRPvcg== Date: Mon, 24 Mar 2025 09:04:50 +0100 From: Ingo Molnar To: Eric Dumazet Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Peter Zijlstra , Steven Rostedt , linux-kernel , Alexei Starovoitov , Daniel Borkmann , Masami Hiramatsu , x86@kernel.org, bpf@vger.kernel.org, Eric Dumazet , Greg Thelen , Stephane Eranian Subject: Re: [PATCH] x86/alternatives: remove false sharing in poke_int3_handler() Message-ID: References: <20250323072511.2353342-1-edumazet@google.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: * Eric Dumazet wrote: > On Mon, Mar 24, 2025 at 8:47 AM Eric Dumazet wrote: > > > > On Mon, Mar 24, 2025 at 8:16 AM Ingo Molnar wrote: > > > > > > > > > * Eric Dumazet wrote: > > > > > > > > What's the adversarial workload here? Spamming bpf_stats_enabled on all > > > > > CPUs in parallel? Or mixing it with some other text_poke_bp_batch() > > > > > user if bpf_stats_enabled serializes access? > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > Does anything undesirable happen in that case? > > > > > > > > The case of multiple threads trying to flip bpf_stats_enabled is > > > > handled by bpf_stats_enabled_mutex. > > > > > > So my suggested workload wasn't adversarial enough due to > > > bpf_stats_enabled_mutex: how about some other workload that doesn't > > > serialize access to text_poke_bp_batch()? > > > > Do you have a specific case in mind that I can test on these big platforms ? > > > > text_poke_bp_batch() calls themselves are serialized by text_mutex, it > > is not clear what you are looking for. > > > BTW the atomic_cond_read_acquire() part is never called even during my > stress test. Yeah, that code threw me off - can it really happen with text_mutex serializing all of it? > @@ -2418,7 +2418,7 @@ static void text_poke_bp_batch(struct > text_poke_loc *tp, unsigned int nr_entries > for_each_possible_cpu(i) { > atomic_t *refs = per_cpu_ptr(&bp_refs, i); > > - if (!atomic_dec_and_test(refs)) > + if (unlikely(!atomic_dec_and_test(refs))) > atomic_cond_read_acquire(refs, !VAL); If it could never happen then this should that condition be a WARN_ON_ONCE() perhaps? Thanks, Ingo