doc: fix formatting

doc/chapters/sched_ctx_hypervisor.texi

@@ -35,7 +35,7 @@ These performance counters represent actually some callbacks that will be used b
 Note: The Hypervisor is actually a worker that takes this role once certain conditions trigger the resizing process (there is no additional thread assigned to the hypervisor).
 
 @deftypefun void sched_ctx_hypervisor_shutdown (void)
-The hypervisor and all information is freed. There is no synchronization between this function and starpu_shutdown. Thus, this should be done after starpu_shutdown(), 
+The hypervisor and all information is freed. There is no synchronization between this function and starpu_shutdown. Thus, this should be done after starpu_shutdown(),
 because the performance counters will still need allocated callback functions.
 @end deftypefun
 
@@ -69,14 +69,14 @@ The user can then provide information to the hypervisor concerning the condition
 Inputs conditions to the context @code{sched_ctx} with the following arguments.  The argument list must be zero-terminated.
 
 @defmac HYPERVISOR_MAX_IDLE
-This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 3 arguments: 
-an array of int for the workerids to apply the condition, an int to indicate the size of the array, and a double value indicating 
+This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 3 arguments:
+an array of int for the workerids to apply the condition, an int to indicate the size of the array, and a double value indicating
 the maximum idle time allowed for a worker before the resizing process should be triggered
 @end defmac
 
 @defmac HYPERVISOR_PRIORITY
-This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 3 arguments: 
-an array of int for the workerids to apply the condition, an int to indicate the size of the array, and an int value indicating 
+This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 3 arguments:
+an array of int for the workerids to apply the condition, an int to indicate the size of the array, and an int value indicating
 the priority of the workers previously mentioned.
 The workers with the smallest priority are moved the first.
 @end defmac
@@ -87,7 +87,7 @@ the minimum number of workers a context should have, underneath this limit the c
 @end defmac
 
 @defmac HYPERVISOR_MAX_WORKERS
-This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 1 argument(int) indicating 
+This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 1 argument(int) indicating
 the maximum number of workers a context should have, above this limit the context would not be able to scale
 @end defmac
 
@@ -97,8 +97,8 @@ the granularity of the resizing process (the number of workers should be moved f
 This parameter is ignore for the Gflops rate based strategy @pxref{Resizing strategies}, the number of workers that have to be moved is calculated by the strategy.
 @end defmac
 
-@defmac HYPERVISOR_FIXED_WORKERS 
-This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 2 arguments: 
+@defmac HYPERVISOR_FIXED_WORKERS
+This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 2 arguments:
 an array of int for the workerids to apply the condition and an int to indicate the size of the array.
 These workers are not allowed to be moved from the context.
 @end defmac
@@ -110,7 +110,7 @@ This parameter is ignored for the Application Driven strategy @pxref{Resizing st
 @end defmac
 
 @defmac HYPERVISOR_NEW_WORKERS_MAX_IDLE
-This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 1 argument, a double value indicating 
+This macro is used when calling sched_ctx_hypervisor_ioctl and must be followed by 1 argument, a double value indicating
 the maximum idle time allowed for workers that have just been moved from other contexts in the current context.
 @end defmac
 
@@ -124,9 +124,9 @@ an executed task should have such that this configuration should be taken into a
 
 The plugin proposes several strategies for resizing the scheduling context.
 
-The @b{Application driven} strategy uses the user's input concerning the moment when he wants to resize the contexts. 
+The @b{Application driven} strategy uses the user's input concerning the moment when he wants to resize the contexts.
 Thus, the users tags the task that should trigger the resizing process. We can set directly the corresponding field in the @code{starpu_task} data structure is @code{hypervisor_tag} or
-use the macro @code{STARPU_HYPERVISOR_TAG} in @code{starpu_insert_task} function. 
+use the macro @code{STARPU_HYPERVISOR_TAG} in @code{starpu_insert_task} function.
 
 @cartouche
 @smallexample
@@ -138,15 +138,14 @@ or
 
 @cartouche
 @smallexample
-@{starpu_insert_task(&codelet,
+starpu_insert_task(&codelet,
 		    ...,
 		    STARPU_HYPERVISOR_TAG, 2,
                     0);
-@}
 @end smallexample
 @end cartouche
 
-The the user has to indicate that when a task with the specified tag is executed the contexts should resize.
+Then the user has to indicate that when a task with the specified tag is executed the contexts should resize.
 
 @cartouche
 @smallexample
@@ -158,15 +157,15 @@ The user can use the same tag to change the resizing configuration of the contex
 @cartouche
 @smallexample
 sched_ctx_hypervisor_ioctl(sched_ctx,
-                          HYPERVISOR_MIN_WORKERS, 6,
-                          HYPERVISOR_MAX_WORKERS, 12,
-                          HYPERVISOR_TIME_TO_APPLY, 2,
-                          NULL);
+                    HYPERVISOR_MIN_WORKERS, 6,
+                    HYPERVISOR_MAX_WORKERS, 12,
+                    HYPERVISOR_TIME_TO_APPLY, 2,
+                    NULL);
 @end smallexample
 @end cartouche
 
 
-The @b{Idleness} based strategy resizes the scheduling contexts every time one of their workers stays idle 
+The @b{Idleness} based strategy resizes the scheduling contexts every time one of their workers stays idle
 for a period longer than the one imposed by the user (see @pxref{The user's input in the resizing process})
 
 @cartouche
@@ -174,20 +173,20 @@ for a period longer than the one imposed by the user (see @pxref{The user's inpu
 int workerids[3] = @{1, 3, 10@};
 int workerids2[9] = @{0, 2, 4, 5, 6, 7, 8, 9, 11@};
 sched_ctx_hypervisor_ioctl(sched_ctx_id,
-                           HYPERVISOR_MAX_IDLE, workerids, 3, 10000.0,
-			   HYPERVISOR_MAX_IDLE, workerids2, 9, 50000.0,
-                           NULL);
+            HYPERVISOR_MAX_IDLE, workerids, 3, 10000.0,
+            HYPERVISOR_MAX_IDLE, workerids2, 9, 50000.0,
+            NULL);
 @end smallexample
 @end cartouche
 
-The @b{Gflops rate} based strategy resizes the scheduling contexts such that they all finish at the same time. 
+The @b{Gflops rate} based strategy resizes the scheduling contexts such that they all finish at the same time.
 The velocity of each of them is considered and once one of them is significantly slower the resizing process is triggered.
-In order to do these computations the user has to input the total number of instructions needed to be executed by the 
+In order to do these computations the user has to input the total number of instructions needed to be executed by the
 parallel kernels and the number of instruction to be executed by each task.
 The number of flops to be executed by a context are passed as parameter when they are registered to the hypervisor,
  (@code{sched_ctx_hypervisor_register_ctx(sched_ctx_id, flops)}) and the one to be executed by each task are passed when the task is submitted.
-The corresponding field in the @code{starpu_task} data structure is @code{flops} and 
-the corresponding macro in @code{starpu_insert_task} function is @code{STARPU_FLOPS}. When the task is executed 
+The corresponding field in the @code{starpu_task} data structure is @code{flops} and
+the corresponding macro in @code{starpu_insert_task} function is @code{STARPU_FLOPS}. When the task is executed
 the resizing process is triggered.
 @cartouche
 @smallexample
@@ -200,8 +199,8 @@ or
 @cartouche
 @smallexample
 starpu_insert_task(&codelet,
-		    ...,
-		    STARPU_FLOPS, 100,
+                    ...,
+                    STARPU_FLOPS, 100,
                     0);
 @end smallexample
 @end cartouche
@@ -243,13 +242,13 @@ TODO maybe they should be hidden to the user
 @node Hypervisor Policy API
 @subsection Hypervisor Policy API
 
-While Scheduling Context Hypervisor Plugin comes with a variety of resizing policies (@pxref{Resizing strategies}), 
+While Scheduling Context Hypervisor Plugin comes with a variety of resizing policies (@pxref{Resizing strategies}),
 it may sometimes be desirable to implement custom
 policies to address specific problems.  The API described below allows
 users to write their own resizing policy.
 
 @deftp {Data Type} {struct starpu_sched_ctx_hypervisor_policy}
-This structure contains all the methods that implement a hypervisor resizing policy. 
+This structure contains all the methods that implement a hypervisor resizing policy.
 
 @table @asis
 @item @code{const char* name}
@@ -375,7 +374,7 @@ Returns the name of the resizing policy the hypervisor uses
 @cartouche
 @smallexample
 
-struct starpu_sched_ctx_hypervisor_policy dummy_policy = 
+struct starpu_sched_ctx_hypervisor_policy dummy_policy =
 @{
        .handle_poped_task = dummy_handle_poped_task,
        .handle_pushed_task = dummy_handle_pushed_task,
@@ -383,7 +382,7 @@ struct starpu_sched_ctx_hypervisor_policy dummy_policy =
        .handle_idle_end = dummy_handle_idle_end,
        .handle_post_exec_hook = dummy_handle_post_exec_hook,
        .custom = 1,
-       .name = ``dummy''
+       .name = "dummy"
 @};
 
 @end smallexample