On Sun, 5 Feb 2023 10:21:26 -0800, SeongJae Park wrote:
> From: SeongJae Park <sj38.park@xxxxxxxxx>
>
> Some sentences in debugging.tex encloses 'rcutorture' with while some
> others don't. Use \co{} consistently.
Ya, that's also the convention in defer/rcurelated.tex.
>
> Signed-off-by: SeongJae Park <sj38.park@xxxxxxxxx
Reviewed-by: Akira Yokosawa <akiyks@xxxxxxxxx>
> ---
> debugging/debugging.tex | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> index 3ce74469..1903c5db 100644
> --- a/debugging/debugging.tex
> +++ b/debugging/debugging.tex
> @@ -697,7 +697,7 @@ what it knows is almost always way more than your head can hold.
> For this reason, high-quality test suites normally come with sophisticated
> scripts to analyze the voluminous output.
> But beware---scripts will only notice what you tell them to.
> -My rcutorture scripts are a case in point:
> +My \co{rcutorture} scripts are a case in point:
> Early versions of those scripts were quite satisfied with a test run
> in which RCU \IXpl{grace period} stalled indefinitely.
> This of course resulted in the scripts being modified to detect RCU
> @@ -1252,14 +1252,14 @@ of time you spent testing.
> Functional tests tend to be discrete.
>
> On the other hand, if my patch involved RCU, I would probably run
> -rcutorture, which is a kernel module that, strangely enough, tests RCU\@.
> +\co{rcutorture}, which is a kernel module that, strangely enough, tests RCU\@.
> Unlike booting the kernel, where the appearance of a login prompt
> -signals the successful end of a discrete test, rcutorture will happily
> +signals the successful end of a discrete test, \co{rcutorture} will happily
> continue torturing RCU until either the kernel crashes or until you
> tell it to stop.
> -The duration of the rcutorture test is usually of more
> +The duration of the \co{rcutorture} test is usually of more
> interest than the number of times you started and stopped it.
> -Therefore, rcutorture is an example of a continuous test, a category
> +Therefore, \co{rcutorture} is an example of a continuous test, a category
> that includes many stress tests.
>
> Statistics for discrete tests are simpler and more familiar than those
> @@ -1845,7 +1845,7 @@ If the program is structured such that it is difficult or impossible
> to apply much stress to a subsystem that is under suspicion,
> a useful anti-heisenbug is a stress test that tests that subsystem in
> isolation.
> -The Linux kernel's rcutorture module takes exactly this approach with RCU\@:
> +The Linux kernel's \co{rcutorture} module takes exactly this approach with RCU\@:
> Applying more stress to RCU than is feasible in a production environment
> increases the probability that RCU bugs will be found during testing
> rather than in production.\footnote{
> @@ -1918,7 +1918,7 @@ delay might be counted as a near miss.\footnote{
> \end{figure}
>
> For example, a low-probability bug in RCU priority boosting occurred
> -roughly once every hundred hours of focused rcutorture testing.
> +roughly once every hundred hours of focused \co{rcutorture} testing.
> Because it would take almost 500 hours of failure-free testing to be
> 99\,\% certain that the bug's probability had been significantly reduced,
> the \co{git bisect} process
