linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
	niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
	rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
	darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu
Subject: Re: [PATCH tip/core/rcu 2/3] rcu: Update RTFP documentation
Date: Sun, 18 Aug 2013 21:09:23 -0700	[thread overview]
Message-ID: <20130819040923.GG29406@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130819003850.GA10079@leaf>

On Sun, Aug 18, 2013 at 05:38:51PM -0700, Josh Triplett wrote:
> On Sun, Aug 18, 2013 at 05:20:02PM -0700, Paul E. McKenney wrote:
> > On Sat, Aug 17, 2013 at 07:46:30PM -0700, Josh Triplett wrote:
> > > On Sat, Aug 17, 2013 at 06:25:52PM -0700, Paul E. McKenney wrote:
> > > > +In 2012, Josh Triplett received his Ph.D. with his dissertation
> > > > +covering RCU-protected resizable hash tables and the relationship
> > > > +between memory barriers and read-side traversal order:  If the updater
> > > > +is making changes in the opposite direction from the read-side traveral
> > > > +order, the updater need only execute a memory-barrier instruction,
> > > > +but if in the same direction, the updater needs to wait for a grace
> > > > +period between the individual updates [JoshTriplettPhD].  Also in 2012,
> > > 
> > > :)
> > > 
> > > > +after seventeen years of attempts, an RCU paper made it into a top-flight
> > > > +academic journal, IEEE Transactions on Parallel and Distributed Systems
> > > > +[MathieuDesnoyers2012URCU].  A group of researchers in Spain applied
> > > 
> > > What about the 2010 paper in Operating Systems Review?
> > 
> > It is already there, but not visible in this patch:
> > 
> > 	2010 produced a simpler preemptible-RCU implementation
> > 	based on TREE_RCU [PaulEMcKenney2010SimpleOptRCU], lockdep-RCU
> > 	[PaulEMcKenney2010LockdepRCU], another resizeable RCU-protected hash
> > 	table [HerbertXu2010RCUResizeHash] (this one consuming more memory,
> > 	but allowing arbitrary changes in hash function, as required for DoS
> > 	avoidance in the networking code), realization of the 2009 RCU-protected
> > 	hash table with atomic node move [JoshTriplett2010RPHash], an update on
> > 	the RCU API [PaulEMcKenney2010RCUAPI].
> > 
> > And:
> > 
> > 	@article{JoshTriplett2010RPHash
> > 	,author="Josh Triplett and Paul E. McKenney and Jonathan Walpole"
> > 	,title="Scalable Concurrent Hash Tables via Relativistic Programming"
> > 	,journal="ACM Operating Systems Review"
> > 	,year=2010
> > 	,volume=44
> > 	,number=3
> > 	,month="July"
> > 	,annotation={
> > 	        RP fun with hash tables.
> > 		http://portal.acm.org/citation.cfm?id=1842733.1842750
> > 	}
> 
> Right, I saw it in the file when I checked; I meant, that journal paper
> seems to contradict "after seventeen years of attempts, an RCU paper
> made it into a top-flight academic journal". :)

Ah, from what I can see, OSR is on its way up, but still mid-ranks.
(Some years back, it was low-end -- unreviewed.)

> > > > +,day = {25}
> > > > +,doi = {10.1007/s11227-012-0766-x}
> > > > +,issn = {0920-8542}
> > > > +,journal = {The Journal of Supercomputing}
> > > > +,keywords = {linux, simulation}
> > > > +,month = apr
> > > > +,posted-at = {2012-05-03 09:12:04}
> > > > +,priority = {2}
> > > > +,title = {{A Read-Copy Update based parallel server for distributed crowd simulations}}
> > > > +,url = {http://dx.doi.org/10.1007/s11227-012-0766-x}
> > > > +,year = {2012}
> > > > +}
> > > > +
> > > > +
> > > > +@unpublished{JonCorbet2012ACCESS:ONCE
> > > 
> > > LWN is not "unpublished"; it's at least "misc", and I'd suggest
> > > "article".  Ditto for every other LWN cite in this bibliography.
> > 
> > There does seem to be a diverse set of advice out there, with some
> > agreeing with you on "misc", others advocating for "electronic", and
> > still others suggesting use of LaBibTex with its "online" tag, and with
> > the Tex Frequently Asked Questions page saying:
> > 
> > 	There is no citation type for URLs, per se, in the standard
> > 	BibTeX styles, though Oren Patashnik (the author of BibTeX)
> > 	is believed to be considering developing one such for use with
> > 	the long-awaited BibTeX version 1.0.
> > 
> > I couldn't find any online .bib files with entries for Linux Weekly News
> > articles.  Other than my own, of course!  (I know people have cited
> > them in papers, but Google doesn't see the corresponding .bib files.)
> > 
> > Given all that, I am going to stick with "unpublished" for the moment,
> > and wait at least one year to see if BibTex version 1.0 comes out.
> 
> Several different tags make sense, but "unpublished" isn't one of them.
> "unpublished" exists for entirely un-reviewed works such as self-hosted
> PDFs.  LWN has editorial standards.  Thus, of the standard tags that
> work with all BibTeX styles, I think either "article" or "misc" would
> make more sense than "unpublished".
> 
> An example from one of my own .bib files:
> 
> @article{tiny-rcu-lwn,
> author = "Paul E. McKenney",
> title = {{RCU: The Bloatwatch Edition}},
> journal = "Linux Weekly News",
> month = "March",
> year = "2009",
> day = "17",
> url = {https://lwn.net/Articles/323929/}
> }
> 
> (With the obvious change that since you don't use "url" in your .bib
> files, that should go in "howpublished" or "note" instead.)

I might do this at some point, but don't want to do it twice.  If Patashnik
hasn't released a new BibTeX by this time next year, I will probably go
with "misc".

I do agree that LWN deserves more respect, but on the other hand, RTFP.txt
has been using "unpublished" since January 2008, so I am willing to hold
off another year.  ;-)

							Thanx, Paul


  reply	other threads:[~2013-08-19  4:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-18  1:25 [PATCH tip/core/rcu 0/3] Documentation updates for 3.12 Paul E. McKenney
2013-08-18  1:25 ` [PATCH tip/core/rcu 1/3] rcu: Fix rcu_barrier() documentation Paul E. McKenney
2013-08-18  1:25   ` [PATCH tip/core/rcu 2/3] rcu: Update RTFP documentation Paul E. McKenney
2013-08-18  2:46     ` Josh Triplett
2013-08-19  0:20       ` Paul E. McKenney
2013-08-19  0:38         ` Josh Triplett
2013-08-19  4:09           ` Paul E. McKenney [this message]
2013-08-18  1:25   ` [PATCH tip/core/rcu 3/3] doc: Fix memory-barrier control-dependency example Paul E. McKenney
2013-08-18  2:47 ` [PATCH tip/core/rcu 0/3] Documentation updates for 3.12 Josh Triplett
2013-08-20  7:09 ` Rob Landley
2013-08-20 13:39   ` Paul E. McKenney
  -- strict thread matches above, loose matches on Subject: below --
2013-08-20  2:37 [PATCH tip/core/rcu 0/3] v2 " Paul E. McKenney
2013-08-20  2:37 ` [PATCH tip/core/rcu 1/3] rcu: Fix rcu_barrier() documentation Paul E. McKenney
2013-08-20  2:37   ` [PATCH tip/core/rcu 2/3] rcu: Update RTFP documentation Paul E. McKenney
2013-08-20  3:22     ` Josh Triplett

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=20130819040923.GG29406@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=darren@dvhart.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=niv@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sbw@mit.edu \
    --cc=tglx@linutronix.de \
    /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).