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
next prev parent 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).