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