DOC minor broken links fix in parallelism docs (#19151)

NicolasHug · thomasjpfan · jeremiedbb · commit 990bf984bdfe · 2021-01-19T11:28:01.000+01:00
Co-authored-by: Thomas J. Fan &lt;thomasjpfan@gmail.com&gt;
diff --git a/doc/computing/parallelism.rst b/doc/computing/parallelism.rst
@@ -114,9 +114,11 @@ threads than the number of CPUs on a machine. Over-subscription happens when
 a program is running too many threads at the same time.
 
 Suppose you have a machine with 8 CPUs. Consider a case where you're running
-a :class:`~GridSearchCV` (parallelized with joblib) with ``n_jobs=8`` over
-a :class:`~HistGradientBoostingClassifier` (parallelized with OpenMP). Each
-instance of :class:`~HistGradientBoostingClassifier` will spawn 8 threads
+a :class:`~sklearn.model_selection.GridSearchCV` (parallelized with joblib)
+with ``n_jobs=8`` over a
+:class:`~sklearn.ensemble.HistGradientBoostingClassifier` (parallelized with
+OpenMP). Each instance of
+:class:`~sklearn.ensemble.HistGradientBoostingClassifier` will spawn 8 threads
 (since you have 8 CPUs). That's a total of ``8 * 8 = 64`` threads, which
 leads to oversubscription of physical CPU resources and to scheduling
 overhead.
@@ -129,9 +131,10 @@ is the default), joblib will tell its child **processes** to limit the
 number of threads they can use, so as to avoid oversubscription. In practice
 the heuristic that joblib uses is to tell the processes to use ``max_threads
 = n_cpus // n_jobs``, via their corresponding environment variable. Back to
-our example from above, since the joblib backend of :class:`~GridSearchCV`
-is ``loky``, each process will only be able to use 1 thread instead of 8,
-thus mitigating the oversubscription issue.
+our example from above, since the joblib backend of
+:class:`~sklearn.model_selection.GridSearchCV` is ``loky``, each process will
+only be able to use 1 thread instead of 8, thus mitigating the
+oversubscription issue.
 
 Note that:
 
