From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sOwcM4/Dk2QHdwoAWB0awg (envelope-from ) for ; Wed, 21 Jun 2023 23:44:15 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=lists.lttng.org header.i=@lists.lttng.org header.a=rsa-sha256 header.s=default header.b=lad4d5TM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C0D7F1E0BB; Wed, 21 Jun 2023 23:44:15 -0400 (EDT) Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 73EDD1E00F for ; Wed, 21 Jun 2023 23:44:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1687405453; bh=NlNFGRjRjwMCGgB8mk+o2P/gohDfsMNwanJecWL6Mzg=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=lad4d5TMmvFkRaVX9KA0jmG+ymknPInBAglzpxQ+Rc/7+yNS/Jn44xPkpUCUph6vq BZfU3BIEykG85OpHGxj/xpOgZUt4ue9HlAOQrgQUV8JsoBeKxsvsxXYy+wTP8UecVc 82P8h71j6Raoy5FxHIJiQh7K4Sq0umeYxrwvFdt12pT0OK27wwIeY9Q4INkbnL3zBG vb/DzDDTT6HQDhfditBUHYSqeX10WKH/DSHaxVclCU/ZSd5cLvobikFI/hLEWT5YoV CSk/i06bmLK1pLZliF9LIDN8sNIwQkQljfmAX6K+1p74E1wA6Wz1jdrA5ZrDSnE2X9 jcPL6/4r3GLAQ== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4QmmSr5p5jz1ykf; Wed, 21 Jun 2023 23:44:12 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lists.lttng.org (Postfix) with ESMTPS id 4QmmSq5TSFz1ykd for ; Wed, 21 Jun 2023 23:44:11 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 747CE61703; Thu, 22 Jun 2023 03:44:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0338C433C8; Thu, 22 Jun 2023 03:44:09 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 62404CE007D; Wed, 21 Jun 2023 20:44:09 -0700 (PDT) Date: Wed, 21 Jun 2023 20:44:09 -0700 To: Mathieu Desnoyers Cc: Olivier Dion , lttng-dev@lists.lttng.org Message-ID: <639e2d14-651a-4f1c-a121-eb227c3abe15@paulmck-laptop> References: <20230515201718.9809-1-odion@efficios.com> <20230515201718.9809-5-odion@efficios.com> <877crwmi54.fsf@laura> <9ca1c2ca-a027-7178-f552-e0f8fa8f2d2f@efficios.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9ca1c2ca-a027-7178-f552-e0f8fa8f2d2f@efficios.com> Subject: Re: [lttng-dev] [PATCH 04/11] urcu/arch/generic: Use atomic builtins if configured X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Paul E. McKenney via lttng-dev" Reply-To: paulmck@kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" On Wed, Jun 21, 2023 at 09:48:10PM -0400, Mathieu Desnoyers wrote: > On 6/21/23 20:53, Olivier Dion wrote: > > On Wed, 21 Jun 2023, "Paul E. McKenney" wrote: > > > On Mon, May 15, 2023 at 04:17:11PM -0400, Olivier Dion wrote: > > > > #ifndef cmm_mb > > > > #define cmm_mb() __sync_synchronize() > > > > > > Just out of curiosity, why not also implement cmm_mb() in terms of > > > __atomic_thread_fence(__ATOMIC_SEQ_CST)? (Or is that a later patch?) > > > > IIRC, Mathieu and I agree that the definition of a thread fence -- acts > > as a synchronization fence between threads -- is too weak for what we > > want here. For example, with I/O devices. > > > > Although __sync_synchronize() is probably an alias for a SEQ_CST thread > > fence, its definition -- issues a full memory barrier -- is stronger. > > > > We do not want to rely on this assumption (alias) and prefer to rely on > > the documented definition instead. > > We should document this rationale with a new comment near the #define, > in case anyone mistakenly decides to use a thread fence there to make it > similar to the rest of the code in the future. That would be good, thank you! Ah, and I did not find any issues with the rest of the patchset. Thanx, Paul _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev