All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Andrea Parri <andrea.parri@amarulasolutions.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] doc/rcu: Correct field_count field naming in examples
Date: Sun, 12 May 2019 23:43:05 -0400	[thread overview]
Message-ID: <20190513034305.GB96252@google.com> (raw)
In-Reply-To: <20190508181638.GY3923@linux.ibm.com>

On Wed, May 08, 2019 at 11:16:38AM -0700, Paul E. McKenney wrote:
[snip]
> > The other example could be dentry look up which uses seqlocks for the
> > RCU-walk case? But that could be too complex. This is also something I first
> > learnt from the paper and then the excellent path-lookup.rst document in
> > kernel sources.
> 
> This is a great example, but it would need serious simplification for
> use in the Documentation/RCU directory.  Note that dcache uses it to
> gain very limited and targeted consistency -- only a few types of updates
> acquire the write-side of that seqlock.
> 
> Might be quite worthwhile to have a simplified example, though!
> Perhaps a trivial hash table where write-side sequence lock is acquired
> only when moving an element from one chain to another?

Here you meant "moving from one chain to another" in the case of
hashtable-resizing right? I could not think of another reason why an element
is moved between 2 hash chains.

I just finished reading the main parts of Josh's relativistic hashtable paper
[1] and it is very cool indeed. The whole wait-for-readers application for
hashtable expansion is so well thought. I am planning to go over more papers
and code and can certainly update this example with a read-mostly hashtable
example as well as you are suggesting. :-)

[1] https://www.usenix.org/legacy/event/atc11/tech/final_files/Triplett.pdf

thanks,

 - Joel


  parent reply	other threads:[~2019-05-13  3:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-05  2:03 [PATCH] doc/rcu: Correct field_count field naming in examples Joel Fernandes (Google)
2019-05-07  0:04 ` Paul E. McKenney
2019-05-08 16:26   ` Joel Fernandes
2019-05-08 18:16     ` Paul E. McKenney
2019-05-11 22:11       ` Andrea Parri
2019-05-12  0:41         ` Paul E. McKenney
2019-05-12  1:09           ` Andrea Parri
2019-05-13  3:43       ` Joel Fernandes [this message]
2019-05-14 22:13         ` Paul E. McKenney
2019-05-25 10:07       ` Joel Fernandes

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=20190513034305.GB96252@google.com \
    --to=joel@joelfernandes.org \
    --cc=andrea.parri@amarulasolutions.com \
    --cc=corbet@lwn.net \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.ibm.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.