[PATCH] Getting and setting SEDF scheduling parameters

[PATCH] Getting and setting SEDF scheduling parameters

[John L Griffin]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

This patch addresses three problems in the function sedf_adjdom():

1) Setting certain values during the DOM0_ADJUSTDOM hypercall causes an 
immediate system lockup.  Specifically, the lockup occurs during a 
SCHED_INFO_PUT operation if the user-specified value for period is 
nonzero, extratime is 1, and weight is zero.  (If you'd like my test code 
to verify this, mail me off-list.)  The attached patch tests for the 
invalid combination of (extratime == 1) && (weight == 0), and returns 
-EINVAL if encountered.

2) During the SCHED_SEDF / SCHED_INFO_GET hypercall, an incorrect value is 
returned for weight when (extratime == 1).  The attached patch fixes this 
problem.

3) The code logic in this function is cryptic, and there is not much 
documentation on how the scheduling parameters should be used.  The 
attached patch adds comments to the sedf_adjdom() function, and 
reorders/rewrites the logic of the SCHED_INFO_PUT handling to make the 
code more self-documenting.

Note that this patch makes strong assumptions about how the scheduling 
parameters are used.  So, I recommend someone take a really close look at 
my comments to make sure I've preserved the Xen team's intentions for how 
the SEDF scheduler works. :-)

Signed-off-by: jlg@us.ibm.com


[-- Attachment #2: 2006-01-05-jlg-sedf-scheduling.patch --]
[-- Type: application/octet-stream, Size: 7477 bytes --]

--- orig.xen/common/sched_sedf.c	2006-01-05 11:38:42.000000000 -0500
+++ xen/common/sched_sedf.c	2006-01-05 13:53:14.000000000 -0500
@@ -1378,7 +1378,40 @@ static inline int sedf_adjust_weights(st
     return 0;
 }
 
-/* set or fetch domain scheduling parameters */
+/* sedf_adjdom: set or fetch domain scheduling parameters
+ *
+ * This function is called indirectly by the statement
+ *     SCHED_OP(adjdom, d, cmd);
+ * in $(XEN_ROOT)/xen/common/schedule.c, whenever SEDF scheduling is set
+ * for this domain.
+ *
+ * There are three modes of scheduling supported by the SEDF scheduler:
+ * best-effort, weight-driven, and time-driven.  The mode is selected by
+ * the values given to four of the five domain scheduling parameters
+ * (<period>, <slice>, <extratime>, and <weight>).  The <latency>
+ * parameter is used by the SEDF scheduler, but its value does not
+ * affect which mode is selected.
+ *
+ * Best-effort/scenario 1: If the EXTRA_AWARE bit in the <extratime>
+ * variable is set, then best-effort scheduling of this domain is
+ * selected.  This domain will receive a weighted share of any unused
+ * CPU time after all real-time domains [scenarios 2 and 3] consume
+ * their shares.  The value set for <weight> must be nonzero.  (Any values
+ * set for <period> or <slice> are ignored.)
+ *
+ * Weight-driven/scenario 2: If scenario 1 does not apply [the
+ * EXTRA_AWARE bit is not set], and if a value is set for <weight>, then
+ * weight-driven real-time scheduling of this domain is selected.  This
+ * domain will receive a weighted share of any unallocated CPU time
+ * after all time-driven real-time domains [scenario 3] are allocated
+ * their shares.  (Any values set for <period> or <slice> are ignored.)
+ *
+ * Time-driven/scenario 3: If scenarios 1 and 2 do not apply [the
+ * EXTRA_AWARE bit is not set, and no value is set for <weight>], and if
+ * a value is set for <period>, then time-driven real-time scheduling of
+ * this domain is selected.  This domain will receive <slice>
+ * nanoseconds of processing during every <period>-nanosecond slot.
+ */
 static int sedf_adjdom(struct domain *p, struct sched_adjdom_cmd *cmd) {
     struct vcpu *v;
 
@@ -1386,61 +1419,95 @@ static int sedf_adjdom(struct domain *p,
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, cmd->u.sedf.period, cmd->u.sedf.slice,
           cmd->u.sedf.latency, (cmd->u.sedf.extratime)?"yes":"no");
-    if ( cmd->direction == SCHED_INFO_PUT )
-    {
-        /*check for sane parameters*/
-        if (!cmd->u.sedf.period && !cmd->u.sedf.weight)
-            return -EINVAL;
-        if (cmd->u.sedf.weight) {
-            if ((cmd->u.sedf.extratime & EXTRA_AWARE) &&
-                (! cmd->u.sedf.period)) {
-                /*weight driven domains with xtime ONLY!*/
-                for_each_vcpu(p, v) {
-                    EDOM_INFO(v)->extraweight = cmd->u.sedf.weight;
-                    EDOM_INFO(v)->weight = 0;
-                    EDOM_INFO(v)->slice = 0;
-                    EDOM_INFO(v)->period = WEIGHT_PERIOD;
-                }
-            } else {
-                /*weight driven domains with real-time execution*/
-                for_each_vcpu(p, v)
-                    EDOM_INFO(v)->weight = cmd->u.sedf.weight;
+
+    switch (cmd->direction) {
+
+    case SCHED_INFO_PUT:
+
+        if (cmd->u.sedf.extratime & EXTRA_AWARE) {
+            /* Scenario 1/4: Extratime scheduling is indicated.  This
+             * means that the domain should run in "best-effort" mode.
+             */
+
+            if (!(cmd->u.sedf.weight))
+                return -EINVAL;
+
+            for_each_vcpu(p, v) {
+                EDOM_INFO(v)->period      = WEIGHT_PERIOD;
+                EDOM_INFO(v)->slice       = 0;
+                EDOM_INFO(v)->latency     = cmd->u.sedf.latency;
+                EDOM_INFO(v)->weight      = 0;
+                EDOM_INFO(v)->extraweight = cmd->u.sedf.weight;
+
+                EDOM_INFO(v)->status |= EXTRA_AWARE;  /* Set bit */
+                extraq_check(v);
             }
         }
-        else {
-            /*time driven domains*/
+        else if (cmd->u.sedf.weight) {
+            /* Scenario 2/4: A scheduling weight is provided, indicating
+             * weight-driven real-time scheduling for this domain. */
+
             for_each_vcpu(p, v) {
-                /* sanity checking! */
-                if(cmd->u.sedf.slice > cmd->u.sedf.period )
-                    return -EINVAL;
-                EDOM_INFO(v)->weight = 0;
+                /* EDOM_INFO(v)->period set by sedf_adjust_weights() */
+                /* EDOM_INFO(v)->slice  set by sedf_adjust_weights() */
+                EDOM_INFO(v)->latency     = cmd->u.sedf.latency;
+                EDOM_INFO(v)->weight      = cmd->u.sedf.weight;
                 EDOM_INFO(v)->extraweight = 0;
-                EDOM_INFO(v)->period_orig = 
-                    EDOM_INFO(v)->period   = cmd->u.sedf.period;
-                EDOM_INFO(v)->slice_orig  = 
-                    EDOM_INFO(v)->slice    = cmd->u.sedf.slice;
+
+                EDOM_INFO(v)->status &= ~EXTRA_AWARE;  /* Unset bit */
+                extraq_check(v);
             }
         }
-        if (sedf_adjust_weights(cmd))
+        else if (cmd->u.sedf.period) {
+            /* Scenario 3/4: A scheduling period is provided, indicating
+             * time-driven real-time scheduling for this domain. */
+
+            if (cmd->u.sedf.slice > cmd->u.sedf.period)
+                return -EINVAL;
+
+            for_each_vcpu(p, v) {
+                EDOM_INFO(v)->period_orig= 
+                    EDOM_INFO(v)->period  = cmd->u.sedf.period;
+                EDOM_INFO(v)->slice_orig = 
+                    EDOM_INFO(v)->slice   = cmd->u.sedf.slice;
+                EDOM_INFO(v)->latency     = cmd->u.sedf.latency;
+                EDOM_INFO(v)->weight      = 0;
+                EDOM_INFO(v)->extraweight = 0;
+
+                EDOM_INFO(v)->status &= ~EXTRA_AWARE;  /* Unset bit */
+                extraq_check(v);
+            }
+        }
+        else {
+            /* Scenario 4/4: If none of the above scenarios apply, then
+             * the parameters provided are invalid. */
+
             return -EINVAL;
-   
-        for_each_vcpu(p, v) {
-            EDOM_INFO(v)->status  = 
-                (EDOM_INFO(v)->status &
-                 ~EXTRA_AWARE) | (cmd->u.sedf.extratime & EXTRA_AWARE);
-            EDOM_INFO(v)->latency = cmd->u.sedf.latency;
-            extraq_check(v);
         }
-    }
-    else if ( cmd->direction == SCHED_INFO_GET )
-    {
+
+        sedf_adjust_weights(cmd);
+
+        break;
+
+    case SCHED_INFO_GET:
+
         cmd->u.sedf.period    = EDOM_INFO(p->vcpu[0])->period;
         cmd->u.sedf.slice     = EDOM_INFO(p->vcpu[0])->slice;
-        cmd->u.sedf.extratime = EDOM_INFO(p->vcpu[0])->status
-            & EXTRA_AWARE;
         cmd->u.sedf.latency   = EDOM_INFO(p->vcpu[0])->latency;
-        cmd->u.sedf.weight    = EDOM_INFO(p->vcpu[0])->weight;
+        cmd->u.sedf.extratime = EDOM_INFO(p->vcpu[0])->status & EXTRA_AWARE;
+
+        if (EDOM_INFO(p->vcpu[0])->status & EXTRA_AWARE)
+            cmd->u.sedf.weight = EDOM_INFO(p->vcpu[0])->extraweight;
+        else
+            cmd->u.sedf.weight = EDOM_INFO(p->vcpu[0])->weight;
+
+        break;
+
+    default:
+
+        return -EINVAL;
     }
+
     PRINT(2,"sedf_adjdom_finished\n");
     return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Getting and setting SEDF scheduling parameters

[Keir Fraser]

> Note that this patch makes strong assumptions about how the scheduling 
> parameters are used.  So, I recommend someone take a really close look at 
> my comments to make sure I've preserved the Xen team's intentions for how 
> the SEDF scheduler works. :-)

I think that the current GET/PUT_INFO call is definitely screwed. The
intended use of extratime should be to allow time-driven domains to
get a best-effort weighted slice of otherwise-idle cpu. Extratime is
not a completely separate scheduling category in its own right! :-)

The scheduling logic should be something like: (a) schedule runnable
time-driven domains with time slice left; then (b) schedule runnable
weight-driven domains; then (c) schedule extratime-aware time-driven
domains. Apart from this there is a bunch of scheduler complexity to
try and sanely handle I/O workloads (short-blocking domains).

Depending on how unused time slices are divvied up, it may make sense
to allow real-time-weight-driven domains also to specify
extratime-awareness (depends on whether real-time weights divvy up all
available cpu (non-time-sliced and unused time-sliced), or just the
spare non-time-sliced time according to the predetermined schedule).

 -- Keir

Re: [PATCH] Getting and setting SEDF scheduling parameters

[John L Griffin]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

Here is a new patch to reflect Keir's directions from last Friday.  Note 
that the patch only addresses the GET/PUT_INFO logic (not the correctness 
of the scheduler proper) but the scheduler seems to indeed be doing the 
right thing.

This patch:

1. Fixes an underflow bug in sedf_adjust_weights() that would cause the 
<slice> for a weight-driven domain to be set to a really big number if the 
CPU was already overcommitted.

2. Clarifies the logic in sedf_adjdom().  Whenever (weight==0), 
time-driven scheduling is selected.  Otherwise, weight-driven scheduling 
is selected.  Extratime scheduling works for both modes.  [Note to Keir: 
in re your question, real-time weights only divvy up the spare 
non-time-sliced time according to the predetermined schedule.]

3. Adds a heap of comments to the code, including five examples of how one 
might set the scheduling parameters.  Each of the five examples has been 
non-rigorously tested to work as described, but additional testing is 
warranted.

One additional change I recommend is to add printk()'s to sedf_adjdom() 
that indicate the failure of a scheduling operation, and possibly to 
indicate success as well, but that's not included in this patch.

Signed-off-by: jlg@us.ibm.com


[-- Attachment #2: 2006-01-09-jlg-sedf-scheduling.patch --]
[-- Type: application/octet-stream, Size: 10811 bytes --]

--- orig.xen/common/sched_sedf.c	2006-01-09 11:23:01.000000000 -0500
+++ xen/common/sched_sedf.c	2006-01-09 15:26:59.000000000 -0500
@@ -1560,12 +1560,26 @@ static int sedf_adjust_weights(struct sc
         {
             if ( EDOM_INFO(p)->weight )
             {
+                s_time_t unallocated_time;
+
+                /* This tests for time-driven overcommitment of the
+                 * processor.  If the total time-driven reservation
+                 * <sumt> is less than (WEIGHT_PERIOD - WEIGHT_SAFETY),
+                 * everything is okay.  If this condition is not true,
+                 * then there is no room for weight-driven domains to
+                 * run, so the slice will be set to zero. */
+
+                if (sumt[p->processor] < (WEIGHT_PERIOD - WEIGHT_SAFETY))
+                    unallocated_time = WEIGHT_PERIOD - WEIGHT_SAFETY - 
+                        sumt[p->processor];
+                else
+                    unallocated_time = 0;
+
                 EDOM_INFO(p)->period_orig = 
                     EDOM_INFO(p)->period  = WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =
                     EDOM_INFO(p)->slice   = 
-                    (EDOM_INFO(p)->weight *
-                     (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[p->processor])) / 
+                    (EDOM_INFO(p)->weight * unallocated_time) /
                     sumw[p->processor];
             }
         }
@@ -1575,9 +1589,106 @@ static int sedf_adjust_weights(struct sc
 }
 
 
-/* set or fetch domain scheduling parameters */
-static int sedf_adjdom(struct domain *p, struct sched_adjdom_cmd *cmd)
-{
+/* sedf_adjdom: set or fetch domain scheduling parameters
+ *
+ * This function is called indirectly by the statement
+ *     SCHED_OP(adjdom, d, cmd);
+ * in $(XEN_ROOT)/xen/common/schedule.c, whenever SEDF scheduling is set
+ * for this domain.
+ *
+ * There are five domain scheduling parameters: <period>, <slice>,
+ * <latency>, <extratime>, and <weight>, as described below.
+ *
+ * There are two modes supported by the SEDF scheduler: time-driven
+ * real-time scheduling and weight-driven real-time scheduling.  The
+ * mode is selected by the value of the <weight> parameter:
+ * 
+ *     (weight == 0) selects time-driven scheduling
+ *     (weight != 0) selects weight-driven scheduling
+ *
+ * MODE 1 / TIME-DRIVEN: A time-driven domain will receive <slice>
+ * nanoseconds of processing during every <period>-nanosecond slot.
+ * If (extratime == 1), the domain will also get an additional
+ * best-effort slice of any otherwise-idle CPU time.
+ *
+ *     Example 1: to specify that the domain should use time-driven
+ *     scheduling and receive 5 ms of processing every 25 ms, use these
+ *     parameters:
+ *
+ *         period    = 25000000
+ *         slice     = 5000000
+ *         latency   = 0
+ *         extratime = 0
+ *         weight    = 0
+ *
+ *     Example 2: to specify that the domain should run only in
+ *     best-effort (non-real-time) mode, use these parameters:
+ *
+ *         period    = 0
+ *         slice     = 0
+ *         latency   = 0
+ *         extratime = 1
+ *         weight    = 0
+ *
+ *     Example 3: the above two examples can be combined: to specify
+ *     that the domain should receive at least 5 ms of processing every
+ *     25 ms, plus it should receive an additional share of any
+ *     otherwise idle CPU time, use these parameters:
+ *
+ *         period    = 25000000
+ *         slice     = 5000000
+ *         latency   = 0
+ *         extratime = 1
+ *         weight    = 0
+ *
+ * MODE 2 / WEIGHT-DRIVEN: A weight-driven domain will recieve a
+ * proportional share of any remaining processing time that is not
+ * allocated to the time-driven domains.  If (extratime == 1)], the
+ * domain will also get an additional best-effort slice of any
+ * otherwise-idle CPU.
+ *
+ *     Example 4: to specify that the domain should use weight-driven
+ *     scheduling with weight 2, use these parameters:
+ *
+ *         period    = 0
+ *         slice     = 0
+ *         latency   = 0
+ *         extratime = 0
+ *         weight    = 2
+ *
+ *     Example 5: to specify that the domain should use weight-driven
+ *     scheduling with weight 2, plus it should receive an additional
+ *     share of any otherwise idle CPU time, use these parameters:
+ *
+ *         period    = 0
+ *         slice     = 0
+ *         latency   = 0
+ *         extratime = 1
+ *         weight    = 2
+ *
+ *     Any values set for <period> or <slice> are ignored when <weight>
+ *     is nonzero.
+ *
+ * The <latency> parameter can be used in either mode.
+ * 
+ * WARNING: As specified in sedf_add_task() above, Domain-0 is
+ * statically allocated 75% (15ms/20ms) of the processor when started.
+ * If you will be using the time-driven or weight-driven real-time
+ * capabilities of this software, you must take care not to exceed 100%
+ * of the processor's allocation.  If you do, the real-time guarantees
+ * will fail and any weight-driven domains will receive no scheduling
+ * slots.  (NB: this function should probably be extended to protect
+ * against overcommitment, or at least print a warning to the log in
+ * such conditions.)
+ *
+ * NB: This code assumes that all extratime-aware domains should receive
+ * an equal share of any idle CPU (i.e., it sets extraweight = 1 for
+ * each extratime-aware domain).  As desired, this could be changed:
+ * perhaps by calculating a value for extratime based on the <slice> and
+ * <period> after sedf_adjust_weights() has been called, or simply by
+ * adding an sixth <extraweight> scheduling parameter.
+ */
+static int sedf_adjdom(struct domain *p, struct sched_adjdom_cmd *cmd) {
     struct vcpu *v;
 
     PRINT(2,"sedf_adjdom was called, domain-id %i new period %"PRIu64" "\
@@ -1585,61 +1696,79 @@ static int sedf_adjdom(struct domain *p,
           p->domain_id, cmd->u.sedf.period, cmd->u.sedf.slice,
           cmd->u.sedf.latency, (cmd->u.sedf.extratime)?"yes":"no");
 
-    if ( cmd->direction == SCHED_INFO_PUT )
-    {
-        /*check for sane parameters*/
-        if (!cmd->u.sedf.period && !cmd->u.sedf.weight)
-            return -EINVAL;
-        if (cmd->u.sedf.weight) {
-            if ((cmd->u.sedf.extratime & EXTRA_AWARE) &&
-                (! cmd->u.sedf.period)) {
-                /*weight driven domains with xtime ONLY!*/
-                for_each_vcpu(p, v) {
-                    EDOM_INFO(v)->extraweight = cmd->u.sedf.weight;
-                    EDOM_INFO(v)->weight = 0;
-                    EDOM_INFO(v)->slice = 0;
-                    EDOM_INFO(v)->period = WEIGHT_PERIOD;
+    switch (cmd->direction) {
+
+    case SCHED_INFO_PUT:
+
+        if (cmd->u.sedf.weight == 0) {
+            /* Time-driven real-time scheduling for this domain. */
+
+            if (cmd->u.sedf.slice > cmd->u.sedf.period)
+                return -EINVAL;
+
+            for_each_vcpu(p, v) {
+                /* If no period is specified, then we set (period =
+                 * WEIGHT_PERIOD) here to prevent a division-by-zero
+                 * error in sedf_adjust_weights(). */
+                EDOM_INFO(v)->period_orig = EDOM_INFO(v)->period = 
+                    (cmd->u.sedf.period ? cmd->u.sedf.period : WEIGHT_PERIOD);
+                EDOM_INFO(v)->slice_orig = EDOM_INFO(v)->slice = 
+                    cmd->u.sedf.slice;
+                EDOM_INFO(v)->latency = cmd->u.sedf.latency;
+                EDOM_INFO(v)->weight = 0;
+
+                if (cmd->u.sedf.extratime & EXTRA_AWARE) {
+                    EDOM_INFO(v)->status |= EXTRA_AWARE;  /* Set bit */
+                    EDOM_INFO(v)->extraweight = 1;
+                } else {
+                    EDOM_INFO(v)->status &= ~EXTRA_AWARE;  /* Unset bit */
+                    EDOM_INFO(v)->extraweight = 0;
                 }
-            } else {
-                /*weight driven domains with real-time execution*/
-                for_each_vcpu(p, v)
-                    EDOM_INFO(v)->weight = cmd->u.sedf.weight;
+                extraq_check(v);
             }
         }
-        else {
-            /*time driven domains*/
+        else /* if (cmd->u.sedf.weight != 0) */ {
+            /* Weight-driven real-time scheduling for this domain. */
+
             for_each_vcpu(p, v) {
-                /* sanity checking! */
-                if(cmd->u.sedf.slice > cmd->u.sedf.period )
-                    return -EINVAL;
-                EDOM_INFO(v)->weight = 0;
-                EDOM_INFO(v)->extraweight = 0;
-                EDOM_INFO(v)->period_orig = 
-                    EDOM_INFO(v)->period   = cmd->u.sedf.period;
-                EDOM_INFO(v)->slice_orig  = 
-                    EDOM_INFO(v)->slice    = cmd->u.sedf.slice;
+                /* Any values passed in for <period> or <slice> are
+                 * ignored when using weight-driven scheduling.
+                 * Instead, values for these variables are calculated
+                 * and set by sedf_adjust_weights() below. */
+
+                /* EDOM_INFO(v)->period set by sedf_adjust_weights() */
+                /* EDOM_INFO(v)->slice  set by sedf_adjust_weights() */
+                EDOM_INFO(v)->latency = cmd->u.sedf.latency;
+                EDOM_INFO(v)->weight = cmd->u.sedf.weight;
+
+                if (cmd->u.sedf.extratime & EXTRA_AWARE) {
+                    EDOM_INFO(v)->status |= EXTRA_AWARE;  /* Set bit */
+                    EDOM_INFO(v)->extraweight = 1;
+                } else {
+                    EDOM_INFO(v)->status &= ~EXTRA_AWARE;  /* Unset bit */
+                    EDOM_INFO(v)->extraweight = 0;
+                }
+                extraq_check(v);
             }
         }
-        if (sedf_adjust_weights(cmd))
-            return -EINVAL;
-   
-        for_each_vcpu(p, v) {
-            EDOM_INFO(v)->status  = 
-                (EDOM_INFO(v)->status &
-                 ~EXTRA_AWARE) | (cmd->u.sedf.extratime & EXTRA_AWARE);
-            EDOM_INFO(v)->latency = cmd->u.sedf.latency;
-            extraq_check(v);
-        }
-    }
-    else if ( cmd->direction == SCHED_INFO_GET )
-    {
+
+        sedf_adjust_weights(cmd);
+        break;
+
+    case SCHED_INFO_GET:
+
         cmd->u.sedf.period    = EDOM_INFO(p->vcpu[0])->period;
         cmd->u.sedf.slice     = EDOM_INFO(p->vcpu[0])->slice;
-        cmd->u.sedf.extratime = EDOM_INFO(p->vcpu[0])->status
-            & EXTRA_AWARE;
         cmd->u.sedf.latency   = EDOM_INFO(p->vcpu[0])->latency;
         cmd->u.sedf.weight    = EDOM_INFO(p->vcpu[0])->weight;
+        cmd->u.sedf.extratime = EDOM_INFO(p->vcpu[0])->status & EXTRA_AWARE;
+        break;
+
+    default:
+
+        return -EINVAL;
     }
+
     PRINT(2,"sedf_adjdom_finished\n");
     return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Getting and setting SEDF scheduling parameters

[Stephan Diestelhorst]

Thanks for that,
I'll have a look at it!

Stephan

John L Griffin wrote:

>Here is a new patch to reflect Keir's directions from last Friday.  Note 
>that the patch only addresses the GET/PUT_INFO logic (not the correctness 
>of the scheduler proper) but the scheduler seems to indeed be doing the 
>right thing.
>
>This patch:
>
>1. Fixes an underflow bug in sedf_adjust_weights() that would cause the 
><slice> for a weight-driven domain to be set to a really big number if the 
>CPU was already overcommitted.
>
>2. Clarifies the logic in sedf_adjdom().  Whenever (weight==0), 
>time-driven scheduling is selected.  Otherwise, weight-driven scheduling 
>is selected.  Extratime scheduling works for both modes.  [Note to Keir: 
>in re your question, real-time weights only divvy up the spare 
>non-time-sliced time according to the predetermined schedule.]
>
>3. Adds a heap of comments to the code, including five examples of how one 
>might set the scheduling parameters.  Each of the five examples has been 
>non-rigorously tested to work as described, but additional testing is 
>warranted.
>
>One additional change I recommend is to add printk()'s to sedf_adjdom() 
>that indicate the failure of a scheduling operation, and possibly to 
>indicate success as well, but that's not included in this patch.
>
>Signed-off-by: jlg@us.ibm.com
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>  
>

Re: [PATCH] Getting and setting SEDF scheduling parameters

[Stephan Diestelhorst]

John L Griffin wrote:

>This patch addresses three problems in the function sedf_adjdom():
>
>3) The code logic in this function is cryptic, and there is not much 
>documentation on how the scheduling parameters should be used.  The 
>attached patch adds comments to the sedf_adjdom() function, and 
>reorders/rewrites the logic of the SCHED_INFO_PUT handling to make the 
>code more self-documenting.
>  
>
I know, the main problem is, that there are quite a number of different 
interpretations for some of the values, depending on the others. This 
caused some cryptic code as you point out properly, which I wasn't 
really happy with!

Stephan

>Note that this patch makes strong assumptions about how the scheduling 
>parameters are used.  So, I recommend someone take a really close look at 
>my comments to make sure I've preserved the Xen team's intentions for how 
>the SEDF scheduler works. :-)
>
>Signed-off-by: jlg@us.ibm.com
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>  
>