summaryrefslogtreecommitdiffstats
path: root/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html
Commit message (Collapse)AuthorAgeFilesLines
* docs: rcu: convert some articles from html to ReSTMauro Carvalho Chehab2019-10-291-668/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 4 RCU articles that are written on html format. The way they are, they can't be part of the Linux Kernel documentation body nor share the styles and pdf output. So, convert them to ReST format. This way, make htmldocs and make pdfdocs will produce a documentation output that will be like the original ones, but will be part of the Linux Kernel documentation body. Part of the conversion was done with the help of pandoc, but the result had some broken things that had to be manually fixed. Following are manual changes Mauro made when doing the automatic conversion: Quoting from: https://lore.kernel.org/rcu/20190726154550.5eeae294@coco.lan/ > > At least the pandoc's version I used here has a bug: its conversion > > from html to ReST on those files only start after a <body> tag - or > > when the first quiz table starts. I only discovered that adding a > > <body> at the beginning of the file solve this book at the last > > conversions. > > > > So, for most html->ReST conversions, I manually converted the first > > part of the document, basically stripping html paragraph tags and > > by replacing highlights by the ReST syntax. > > > > Also, all the quiz tables seem to assume some javascript macro or > > css style that would be hiding the answer part until the mouse moves > > to it. Such macro/css was not there at the kernel tree. So, the quiz > > answers have the same color as the background, making them invisible. > > Even if we had such macro/css, this is not portable for pdf/LaTeX output > > (and I'm not sure if this would work with ePub). > > > > So, I ended by manually doing the table conversion. > > > > Finally, I double-checked if the conversions ended ok, addressing any > > issues that might have heppened. > > > > So, after both automatic conversion and manual fixes, I opened both the > > html files produced by Sphinx and the original ones and compared them > > line per line (except for the indexes, as Sphinx produces them > > automatically), in order to see if all information from the original > > files will be there on a format close to what we have on other ReST > > files, fixing any pending issues if any. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
* doc: Remove obsolete RCU update functions from RCU documentationPaul E. McKenney2019-03-261-1/+3
| | | | | | | | | | Now that synchronize_rcu_bh, synchronize_rcu_bh_expedited, call_rcu_bh, rcu_barrier_bh, synchronize_sched, synchronize_sched_expedited, call_rcu_sched, rcu_barrier_sched, get_state_synchronize_sched, and cond_synchronize_sched are obsolete, let's remove them from the documentation aside from a small historical section. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
* rcu: Determine expedited-GP IPI handler at build timePaul E. McKenney2019-01-251-13/+13
| | | | | | | | | | | | | | | Back when there could be multiple RCU flavors running in the same kernel at the same time, it was necessary to specify the expedited grace-period IPI handler at runtime. Now that there is only one RCU flavor, the IPI handler can be determined at build time. There is therefore no longer any reason for the RCU-preempt and RCU-sched IPI handlers to have different names, nor is there any reason to pass these handlers in function arguments and in the data structures enclosing workqueues. This commit therefore makes all these changes, pushing the specification of the expedited grace-period IPI handler down to the point of use. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
* doc: Update information about resched_cpuJoel Fernandes (Google)2018-11-121-3/+3
| | | | | | | | | | Since commit fced9c8cfe6b ("rcu: Avoid resched_cpu() when rescheduling the current CPU"), resched_cpu is not directly called from sync_sched_exp_handler. Update the documentation about the same. Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Cc: <kernel-team@android.com> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
* doc: Fix broken HTML directivePaul E. McKenney2018-08-301-1/+1
| | | | | | This commit adds the needed "<". Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
* doc: Update removal of RCU-bh/sched update machineryPaul E. McKenney2018-08-301-4/+3
| | | | | | | | | | | | | | | The RCU-bh update API is now defined in terms of that of RCU-bh and RCU-sched, so this commit updates the documentation accordingly. In addition, although RCU-sched persists in !PREEMPT kernels, in the PREEMPT case its update API is now defined in terms of that of RCU-preempt, so this commit also updates the documentation accordingly. While in the area, this commit removes the documentation for the now-obsolete synchronize_rcu_mult() and clarifies the Tasks RCU documentation. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
* Documentation: fix ref to workqueue contentTom Saeger2017-10-191-1/+1
| | | | | Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* doc: Add mid-boot operation to expedited grace periodsPaul E. McKenney2017-04-121-3/+44
| | | | | | | | | | | | | This commit adds a description of how expedited grace periods operate during the mid-boot "dead zone", which starts when the scheduler spawns the first kthread and ends when all of RCU's kthreads have been spawned. In short, before mid-boot, synchronous grace periods can be a no-op. After the end of mid-boot, workqueues may be used. During mid-boot, the requesting task drivees the expedited grace period. For more detail, see https://lwn.net/Articles/716148/. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
* rcu: Design documentation for expedited grace periodsPaul E. McKenney2017-01-141-0/+626
This commit adds design documentation for expedited grace periods. This documentation is in HTML rather than the new documentation format because (1) I have prototype documentation already in HTML, and (2) Attempting to learn the new documentation format while creating the design documentation seems likely to result in neither happening in a timely fashion. Once the design documentation is complete, we can start a conversion effort. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org>