From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +Fc5AVSTeGCxegAAWB0awg (envelope-from ) for ; Thu, 15 Apr 2021 15:26:12 -0400 Received: by simark.ca (Postfix, from userid 112) id EB72F1F104; Thu, 15 Apr 2021 15:26:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 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 46A341E783 for ; Thu, 15 Apr 2021 15:26:11 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4FLq8252FGz1BKb; Thu, 15 Apr 2021 15:26:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1618514770; bh=sxbk32q2Lk70sw2do9nlOqVeoQ7hElSvvHCMJtfnMZw=; h=Date:To:Cc:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=XRIWeGe4rp7WCxqDizoKlPnkZGhAl/uTAiG6oNYUw2ouA8OEVAKfx+E6yEHkLZSrw W40RzviV5OxjbMoO6AJUQLHYXiWltuSR5H6gtDKkX8Wndh5O0wszPaEokd6M1xEAee jXQbmICh8mO/D/XqV55pO+grP5LhfeiDame2Q8/9XUajuBoEPTUPemKvf/oRAYrM2F X+/Ho2Ew1bv6Yi2cxb6SH82gac2hXxMUOHSpYO4EZzwnI/WKP88xTA4oVR/v12ErVq QLj59Ce+Jv0/mle16Lva5xvxOdShYwaEsRe+s49m/6HXfyJLpLceKX2FaEfCkT7KyZ CKsS8reA0t2wA== Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4FLq814NZ0z1BKZ for ; Thu, 15 Apr 2021 15:26:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 4795E32FD1C for ; Thu, 15 Apr 2021 15:26:03 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QotttKHqR27J; Thu, 15 Apr 2021 15:26:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 16DFE32FD15; Thu, 15 Apr 2021 15:26:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 16DFE32FD15 X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Po4uVHv3zFcq; Thu, 15 Apr 2021 15:26:01 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 0B6AE32FD0C; Thu, 15 Apr 2021 15:26:01 -0400 (EDT) Date: Thu, 15 Apr 2021 15:26:00 -0400 (EDT) To: lbj Cc: paulmck , lttng-dev Message-ID: <981542164.79155.1618514760912.JavaMail.zimbra@efficios.com> In-Reply-To: References: <219280299.78204.1618502428396.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3996 (ZimbraWebClient - FF87 (Linux)/8.8.15_GA_4007) Thread-Topic: QSBR urcu read lock question Thread-Index: V+qQwZL7SvqGRpcCKGbEmmqqoZ/2RQ== Subject: Re: [lttng-dev] QSBR urcu read lock question X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mathieu Desnoyers via lttng-dev Reply-To: Mathieu Desnoyers Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" ----- On Apr 15, 2021, at 2:11 PM, lbj lbj137@yahoo.com wrote: > Thanks Mathieu. Is it safe to assume that if call_rcu is called twice then the > callbacks are executed in the order that call_rcu was invoked? I think there is > a queue and only one thread that QSBR uses to handle callbacks, i just wanted > to make sure that the queue was a guaranteed fifo. It may very well depend on your configuration. For instance, if an application invokes create_all_cpu_call_rcu_data(), it will create per-cpu worker threads on each possible CPU. In that configuration, a given thread invoking call_rcu() twice (back to back) may be migrated from one CPU to another in between, hence different call-rcu worker threads will be responsible for executing the callbacks, and they can be executed in any order. So even though by careful analysis of your specific application configuration you may presume that the callbacks will be executed in the same order they were invoked, this is not guaranteed by the API, so I would not recommend relying on FIFO order assumptions. And given that the call_rcu API does not guarantee FIFO order, we could eventually decide to change the order of callback execution from FIFO to LIFO if it leads to performance improvements due to better cache locality. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev