EDF schedulers: Support early job releasing.

This patch allows a task to request early releasing
via rt_task parameters to sys_set_task_rt_param().
Note that early releasing can easily peg your CPUs
since early-releasing tasks never suspend to wait for
their next job. As such, early releasing is really
only useful in the context of implementing bandwidth
servers, interrupt handling threads (or any thread that
spends most of its time waiting for an event), or
short-lived computations. If early releasing pegs your
CPUs, then you probably shouldn't be using it.

2 files changed, 24 insertions, 1 deletions

diff --git a/include/litmus/litmus.h b/include/litmus/litmus.h
index 875783e6a67b..81f6a499570b 100644
--- a/include/litmus/litmus.h
+++ b/include/litmus/litmus.h
@@ -63,6 +63,12 @@ void litmus_exit_task(struct task_struct *tsk);
 #define get_release(t)          (tsk_rt(t)->job_params.release)
 #define get_lateness(t)         (tsk_rt(t)->job_params.lateness)
 
+#ifdef CONFIG_ALLOW_EARLY_RELEASE
+#define wants_early_release(t) (tsk_rt(t)->task_params.release_policy == EARLY)
+#else
+#define wants_early_release(t) (0)
+#endif
+
 #define is_hrt(t)               \
         (tsk_rt(t)->task_params.cls == RT_CLASS_HARD)
 #define is_srt(t)               \
diff --git a/include/litmus/rt_param.h b/include/litmus/rt_param.h
index 5487bdb11380..4167508d9862 100644
--- a/include/litmus/rt_param.h
+++ b/include/litmus/rt_param.h
@@ -33,6 +33,22 @@ typedef enum {
         PRECISE_ENFORCEMENT  /* budgets are enforced with hrtimers */
 } budget_policy_t;
 
+typedef enum {
+        /* Jobs are released periodically (provided job precedence
+       constraints are met). */
+        PERIODIC,
+
+        /* Jobs are released sporadically (provided job precedence
+       constraints are met). NOTE: Litmus currently does not
+       distinguish between periodic and sporadic tasks. */
+        SPORADIC = PERIODIC,
+
+    /* Jobs are released immediatly after meeting precedence
+       constraints. Beware this can peg your CPUs if used in
+       the wrong applications. */
+        EARLY
+} release_policy_t;
+
 /* We use the common priority interpretation "lower index == higher priority",
  * which is commonly used in fixed-priority schedulability analysis papers.
  * So, a numerically lower priority value implies higher scheduling priority,
@@ -61,7 +77,8 @@ struct rt_task {
         unsigned int    cpu;
         unsigned int    priority;
         task_class_t    cls;
-        budget_policy_t budget_policy; /* ignored by pfair */
+        budget_policy_t  budget_policy;  /* ignored by pfair */
+        release_policy_t release_policy; /* ignored by non-edf */
 };
 
 union np_flag {