From: paulmck at kernel.org (Paul E. McKenney) Subject: [Linux-kernel-mentees] [PATCH 2/2] Documentation: RCU: Converted arrayRCU.txt to arrayRCU.rst. Date: Mon, 28 Oct 2019 11:02:33 -0700 [thread overview] Message-ID: <20191028180233.GO4465@paulmck-ThinkPad-P72> (raw) In-Reply-To: <20191028151936.27016-1-madhuparnabhowmik04@gmail.com> On Mon, Oct 28, 2019 at 08:49:36PM +0530, madhuparnabhowmik04 at gmail.com wrote: > From: Madhuparna Bhowmik <madhuparnabhowmik04 at gmail.com> > > This patch converts arrayRCU from txt to rst format. > arrayRCU.rst is also added in the index.rst file. > > Signed-off-by: Madhuparna Bhowmik <madhuparnbhowmik04 at gmail.com> > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik04 at gmail.com> Thank you, but this does not apply to the -rcu git repo's "dev" branch. Could you please tell me what commit you developed this against? FYI, the location and much more about -rcu may be found here: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html Thanx, Paul > --- > .../RCU/{arrayRCU.txt => arrayRCU.rst} | 18 ++++++++++++++---- > Documentation/RCU/index.rst | 1 + > 2 files changed, 15 insertions(+), 4 deletions(-) > rename Documentation/RCU/{arrayRCU.txt => arrayRCU.rst} (91%) > > diff --git a/Documentation/RCU/arrayRCU.txt b/Documentation/RCU/arrayRCU.rst > similarity index 91% > rename from Documentation/RCU/arrayRCU.txt > rename to Documentation/RCU/arrayRCU.rst > index f05a9afb2c39..c8a26f7b2577 100644 > --- a/Documentation/RCU/arrayRCU.txt > +++ b/Documentation/RCU/arrayRCU.rst > @@ -1,4 +1,7 @@ > +.. _array_rcu_doc: > + > Using RCU to Protect Read-Mostly Arrays > +======================================= > > > Although RCU is more commonly used to protect linked lists, it can > @@ -26,6 +29,7 @@ described in the following sections. > > > Situation 1: Hash Tables > +------------------------ > > Hash tables are often implemented as an array, where each array entry > has a linked-list hash chain. Each hash chain can be protected by RCU > @@ -34,6 +38,7 @@ to other array-of-list situations, such as radix trees. > > > Situation 2: Static Arrays > +-------------------------- > > Static arrays, where the data (rather than a pointer to the data) is > located in each array element, and where the array is never resized, > @@ -41,11 +46,14 @@ have not been used with RCU. Rik van Riel recommends using seqlock in > this situation, which would also have minimal read-side overhead as long > as updates are rare. > > -Quick Quiz: Why is it so important that updates be rare when > - using seqlock? > +Quick Quiz: > + Why is it so important that updates be rare when using seqlock? > + > +:ref:`Answer to Quick Quiz <answer_quick_quiz_seqlock>` > > > Situation 3: Resizeable Arrays > +------------------------------ > > Use of RCU for resizeable arrays is demonstrated by the grow_ary() > function formerly used by the System V IPC code. The array is used > @@ -60,7 +68,7 @@ the remainder of the new, updates the ids->entries pointer to point to > the new array, and invokes ipc_rcu_putref() to free up the old array. > Note that rcu_assign_pointer() is used to update the ids->entries pointer, > which includes any memory barriers required on whatever architecture > -you are running on. > +you are running on.:: > > static int grow_ary(struct ipc_ids* ids, int newsize) > { > @@ -112,7 +120,7 @@ a simple check suffices. The pointer to the structure corresponding > to the desired IPC object is placed in "out", with NULL indicating > a non-existent entry. After acquiring "out->lock", the "out->deleted" > flag indicates whether the IPC object is in the process of being > -deleted, and, if not, the pointer is returned. > +deleted, and, if not, the pointer is returned.:: > > struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id) > { > @@ -144,8 +152,10 @@ deleted, and, if not, the pointer is returned. > return out; > } > > +.. _answer_quick_quiz_seqlock: > > Answer to Quick Quiz: > + Why is it so important that updates be rare when using seqlock? > > The reason that it is important that updates be rare when > using seqlock is that frequent updates can livelock readers. > diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst > index 340a9725676c..c4586602e7e2 100644 > --- a/Documentation/RCU/index.rst > +++ b/Documentation/RCU/index.rst > @@ -7,6 +7,7 @@ RCU concepts > .. toctree:: > :maxdepth: 1 > > + arrayRCU > rcu > listRCU > UP > -- > 2.17.1 >
WARNING: multiple messages have this Message-ID (diff)
From: paulmck@kernel.org (Paul E. McKenney) Subject: [Linux-kernel-mentees] [PATCH 2/2] Documentation: RCU: Converted arrayRCU.txt to arrayRCU.rst. Date: Mon, 28 Oct 2019 11:02:33 -0700 [thread overview] Message-ID: <20191028180233.GO4465@paulmck-ThinkPad-P72> (raw) Message-ID: <20191028180233.f1AkM8m6Sd20hDpKUqN70XaWfF4o5HTDD0hGzWjHAPY@z> (raw) In-Reply-To: <20191028151936.27016-1-madhuparnabhowmik04@gmail.com> On Mon, Oct 28, 2019 at 08:49:36PM +0530, madhuparnabhowmik04 at gmail.com wrote: > From: Madhuparna Bhowmik <madhuparnabhowmik04 at gmail.com> > > This patch converts arrayRCU from txt to rst format. > arrayRCU.rst is also added in the index.rst file. > > Signed-off-by: Madhuparna Bhowmik <madhuparnbhowmik04 at gmail.com> > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik04 at gmail.com> Thank you, but this does not apply to the -rcu git repo's "dev" branch. Could you please tell me what commit you developed this against? FYI, the location and much more about -rcu may be found here: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html Thanx, Paul > --- > .../RCU/{arrayRCU.txt => arrayRCU.rst} | 18 ++++++++++++++---- > Documentation/RCU/index.rst | 1 + > 2 files changed, 15 insertions(+), 4 deletions(-) > rename Documentation/RCU/{arrayRCU.txt => arrayRCU.rst} (91%) > > diff --git a/Documentation/RCU/arrayRCU.txt b/Documentation/RCU/arrayRCU.rst > similarity index 91% > rename from Documentation/RCU/arrayRCU.txt > rename to Documentation/RCU/arrayRCU.rst > index f05a9afb2c39..c8a26f7b2577 100644 > --- a/Documentation/RCU/arrayRCU.txt > +++ b/Documentation/RCU/arrayRCU.rst > @@ -1,4 +1,7 @@ > +.. _array_rcu_doc: > + > Using RCU to Protect Read-Mostly Arrays > +======================================= > > > Although RCU is more commonly used to protect linked lists, it can > @@ -26,6 +29,7 @@ described in the following sections. > > > Situation 1: Hash Tables > +------------------------ > > Hash tables are often implemented as an array, where each array entry > has a linked-list hash chain. Each hash chain can be protected by RCU > @@ -34,6 +38,7 @@ to other array-of-list situations, such as radix trees. > > > Situation 2: Static Arrays > +-------------------------- > > Static arrays, where the data (rather than a pointer to the data) is > located in each array element, and where the array is never resized, > @@ -41,11 +46,14 @@ have not been used with RCU. Rik van Riel recommends using seqlock in > this situation, which would also have minimal read-side overhead as long > as updates are rare. > > -Quick Quiz: Why is it so important that updates be rare when > - using seqlock? > +Quick Quiz: > + Why is it so important that updates be rare when using seqlock? > + > +:ref:`Answer to Quick Quiz <answer_quick_quiz_seqlock>` > > > Situation 3: Resizeable Arrays > +------------------------------ > > Use of RCU for resizeable arrays is demonstrated by the grow_ary() > function formerly used by the System V IPC code. The array is used > @@ -60,7 +68,7 @@ the remainder of the new, updates the ids->entries pointer to point to > the new array, and invokes ipc_rcu_putref() to free up the old array. > Note that rcu_assign_pointer() is used to update the ids->entries pointer, > which includes any memory barriers required on whatever architecture > -you are running on. > +you are running on.:: > > static int grow_ary(struct ipc_ids* ids, int newsize) > { > @@ -112,7 +120,7 @@ a simple check suffices. The pointer to the structure corresponding > to the desired IPC object is placed in "out", with NULL indicating > a non-existent entry. After acquiring "out->lock", the "out->deleted" > flag indicates whether the IPC object is in the process of being > -deleted, and, if not, the pointer is returned. > +deleted, and, if not, the pointer is returned.:: > > struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id) > { > @@ -144,8 +152,10 @@ deleted, and, if not, the pointer is returned. > return out; > } > > +.. _answer_quick_quiz_seqlock: > > Answer to Quick Quiz: > + Why is it so important that updates be rare when using seqlock? > > The reason that it is important that updates be rare when > using seqlock is that frequent updates can livelock readers. > diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst > index 340a9725676c..c4586602e7e2 100644 > --- a/Documentation/RCU/index.rst > +++ b/Documentation/RCU/index.rst > @@ -7,6 +7,7 @@ RCU concepts > .. toctree:: > :maxdepth: 1 > > + arrayRCU > rcu > listRCU > UP > -- > 2.17.1 >
next prev parent reply other threads:[~2019-10-28 18:02 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-28 15:19 [Linux-kernel-mentees] [PATCH 2/2] Documentation: RCU: Converted arrayRCU.txt to arrayRCU.rst madhuparnabhowmik04 2019-10-28 15:19 ` madhuparnabhowmik04 2019-10-28 18:02 ` paulmck [this message] 2019-10-28 18:02 ` Paul E. McKenney 2019-10-28 15:24 madhuparnabhowmik04 2019-10-28 15:24 ` madhuparnabhowmik04
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=20191028180233.GO4465@paulmck-ThinkPad-P72 \ --to=linux-kernel-mentees@lists.linux-foundation.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: linkBe 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).