lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: lbj <lbj137@yahoo.com>
Cc: paulmck <paulmck@kernel.org>, lttng-dev <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev] QSBR urcu read lock question
Date: Thu, 15 Apr 2021 15:26:00 -0400 (EDT)	[thread overview]
Message-ID: <981542164.79155.1618514760912.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <D6D81B40-920B-46C8-ABBB-9AD856F0D949@yahoo.com>

----- 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

  reply	other threads:[~2021-04-15 19:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <13D87E55-7D1B-49B0-9555-656A837ADEB3.ref@yahoo.com>
2021-04-05 17:43 ` [lttng-dev] QSBR urcu question lbj via lttng-dev
2021-04-06 20:05   ` Mathieu Desnoyers via lttng-dev
2021-04-14  3:19     ` [lttng-dev] QSBR urcu read lock question lbj via lttng-dev
2021-04-15 12:20       ` Mathieu Desnoyers via lttng-dev
2021-04-15 12:41         ` lbj via lttng-dev
2021-04-15 13:04           ` Mathieu Desnoyers via lttng-dev
2021-04-15 14:54             ` lbj via lttng-dev
2021-04-15 16:00               ` Mathieu Desnoyers via lttng-dev
2021-04-15 18:11                 ` lbj via lttng-dev
2021-04-15 19:26                   ` Mathieu Desnoyers via lttng-dev [this message]
2021-04-15 20:58                     ` lbj via lttng-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=981542164.79155.1618514760912.JavaMail.zimbra@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=lbj137@yahoo.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).