lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: lbj via lttng-dev <lttng-dev@lists.lttng.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.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 08:41:10 -0400	[thread overview]
Message-ID: <EDFC028D-682A-433F-9FBD-59617058829D@yahoo.com> (raw)
In-Reply-To: <1791312961.77601.1618489242390.JavaMail.zimbra@efficios.com>

Hi Mathieu,
 When I say “reclamation thread” I do mean the thread launched by call_rcu that is typically responsible for memory deallocations. Is is possible/recommended to register for rcu and then take an rcu-reader lock in such a thread? That is my main question.

As for reader locks being no-ops in QSBR, I read that but dont quite understand it. Something must be preventing memory reclamation of rcu protected elements when I take that lock. 

My specific situation is: I have a QSBR rcu protected “policy” object (just a regular old C++ object that periodically gets refreshed and must be atomically updated because worker cores are reading it while spinning, and they cant slow down). When a new policy is received we invoke call_rcu on the old policy. call_rcu will eventually launch a thread in which the old policy’s resources are reclaimed. In this thread I would like to iterate through another, separate structure, which is also QSBR rcu protected (a urcu hashtable). To do so safely, presumably I must use an rcu readlock. I just want to make sure such a scenario is reasonable and at very least not contra-indicated. Thanks!

Jeff

 

Sent from my iPhone

> On Apr 15, 2021, at 8:20 AM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
> ----- On Apr 13, 2021, at 11:19 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> 
>> Hello all,
>> 
>> I have two different entities that are both protected by QSBR rcu: a policy and
>> a hashtable. In the reclamation thread for the policy I would like to take a
>> read lock so that I can safely iterate through the hashtable. I dont see
>> anything wrong with this, but I just wanted to make sure it was ok since taking
>> an rcu read lock in an rcu reclamation thread seems like it may be a bit
>> suspect. Thanks for any insights, let me know if clarification is needed!
> 
> When you say "the reclamation thread for the policy", do you refer to a call-rcu
> worker thread ?
> 
> Also, you are aware that RCU read-side lock/unlock are effectively no-ops for
> QSBR rcu, right ?
> 
> 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 12:41 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 [this message]
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
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=EDFC028D-682A-433F-9FBD-59617058829D@yahoo.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).