[PATCH v2 0/2] xen: correct changing credit scheduler's timeslice

[PATCH v2 0/2] xen: correct changing credit scheduler's timeslice

[Juergen Gross]

When the timeslice of Xen's credit scheduler is changed via tools the
domain weights are no longer honored correctly.

Changes in V2:
- moved locking to csched_sys_cntl() as suggested by Jan
- split up into two patches as requested by Dario

Juergen Gross (2):
  xen: update timeslice under lock
  xen: recalculate per-cpupool credits when updating timeslice

 xen/common/sched_credit.c | 6 ++++++
 1 file changed, 6 insertions(+)

-- 
2.6.2

[PATCH v2 1/2] xen: update timeslice under lock

[Juergen Gross]

When updating the timeslice of the credit scheduler protect the
scheduler's private data by it's lock. Today a possible race could
result only in some weird scheduling decisions during one timeslice,
but further adjustments will need the lock anyway.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/common/sched_credit.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 03fb2c2..8fbbd54 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1101,6 +1101,7 @@ csched_sys_cntl(const struct scheduler *ops,
     int rc = -EINVAL;
     xen_sysctl_credit_schedule_t *params = &sc->u.sched_credit;
     struct csched_private *prv = CSCHED_PRIV(ops);
+    unsigned long flags;
 
     switch ( sc->cmd )
     {
@@ -1112,8 +1113,12 @@ csched_sys_cntl(const struct scheduler *ops,
                     || params->ratelimit_us < XEN_SYSCTL_SCHED_RATELIMIT_MIN))
             || MICROSECS(params->ratelimit_us) > MILLISECS(params->tslice_ms) )
                 goto out;
+
+        spin_lock_irqsave(&prv->lock, flags);
         __csched_set_tslice(prv, params->tslice_ms);
         prv->ratelimit_us = params->ratelimit_us;
+        spin_unlock_irqrestore(&prv->lock, flags);
+
         /* FALLTHRU */
     case XEN_SYSCTL_SCHEDOP_getinfo:
         params->tslice_ms = prv->tslice_ms;
-- 
2.6.2

[PATCH v2 2/2] xen: recalculate per-cpupool credits when updating timeslice

[Juergen Gross]

When modifying the timeslice of the credit scheduler in a cpupool the
cpupool global credit value (n_cpus * credits_per_tslice) isn't
recalculated. This will lead to wrong scheduling decisions later.

Do the recalculation when updating the timeslice.

Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Alan.Robinson <alan.robinson@ts.fujitsu.com>
---
 xen/common/sched_credit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 8fbbd54..671bbee 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1092,6 +1092,7 @@ __csched_set_tslice(struct csched_private *prv, unsigned timeslice)
         prv->ticks_per_tslice = 1;
     prv->tick_period_us = prv->tslice_ms * 1000 / prv->ticks_per_tslice;
     prv->credits_per_tslice = CSCHED_CREDITS_PER_MSEC * prv->tslice_ms;
+    prv->credit = prv->credits_per_tslice * prv->ncpus;
 }
 
 static int
-- 
2.6.2

Re: [PATCH v2 0/2] xen: correct changing credit scheduler's timeslice

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 927 bytes --]

On Tue, 2016-02-02 at 12:29 +0100, Juergen Gross wrote:
> When the timeslice of Xen's credit scheduler is changed via tools the
> domain weights are no longer honored correctly.
> 
> Changes in V2:
> - moved locking to csched_sys_cntl() as suggested by Jan
> - split up into two patches as requested by Dario
> 
Aha, perfect example of race condition over email! :-P

No big deal, though, I'm fine with this (split) variant.

> Juergen Gross (2):
>   xen: update timeslice under lock
>   xen: recalculate per-cpupool credits when updating timeslice
> 
Both patches:

  Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Thanks,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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