Put back theoretical lower bound paragraph in performance feedback chapter.

doc/chapters/advanced-examples.texi

@@ -12,7 +12,7 @@
 * Task and Worker Profiling::
 * Partitioning Data::
 * Performance model example::
-* Theoretical lower bound on execution time::
+* Theoretical lower bound on execution time example::
 * Insert Task Utility::
 * Data reduction::
 * Temporary buffers::
@@ -446,20 +446,9 @@ for indexing history-based performance models.
 needs to be called to destroy the dummy task afterwards. See
 @code{tests/perfmodels/regression_based.c} for an example.
 
-@node Theoretical lower bound on execution time
+@node Theoretical lower bound on execution time example
 @section Theoretical lower bound on execution time
 
-This API (@pxref{Theoretical lower bound on execution time}) permits
-to record a trace of what tasks are needed to complete the 
-application, and then, by using a linear system, provide a theoretical lower
-bound of the execution time (i.e. with an ideal scheduling).
-
-The computed bound is not really correct when not taking into account
-dependencies, but for an application which have enough parallelism, it is very
-near to the bound computed with dependencies enabled (which takes a huge lot
-more time to compute), and thus provides a good-enough estimation of the ideal
-execution time.
-
 For kernels with history-based performance models (and provided that they are completely calibrated), StarPU can very easily provide a theoretical lower
 bound for the execution time of a whole set of tasks. See for
 instance @code{examples/lu/lu_example.c}: before submitting tasks,

doc/chapters/perf-feedback.texi

@@ -11,6 +11,7 @@
 * On-line::                     On-line performance feedback
 * Off-line::                    Off-line performance feedback
 * Codelet performance::         Performance of codelets
+* Theoretical lower bound on execution time::
 * Memory feedback::
 * Data statistics::
 @end menu
@@ -477,6 +478,22 @@ $ starpu_codelet_histo_profile distrib.data
 Which will create one pdf file per codelet and per input size, showing a
 histogram of the codelet execution time distribution.
 
+@node Theoretical lower bound on execution time
+@section Theoretical lower bound on execution time
+
+StarPU can record a trace of what tasks are needed to complete the
+application, and then, by using a linear system, provide a theoretical lower
+bound of the execution time (i.e. with an ideal scheduling).
+
+The computed bound is not really correct when not taking into account
+dependencies, but for an application which have enough parallelism, it is very
+near to the bound computed with dependencies enabled (which takes a huge lot
+more time to compute), and thus provides a good-enough estimation of the ideal
+execution time.
+
+@ref{Theoretical lower bound on execution time} provides an example on how to
+use this.
+
 @node Memory feedback
 @section Memory feedback