[PATCH] xen: credit2: don't let b_avgload go negative.

[PATCH] xen: credit2: don't let b_avgload go negative.

[Dario Faggioli]

The ASSERT() made effective by b5b5876619bd8ec2e
("xen: credit2: fix two s_time_t handling issues
in load balancing") triggers for b_avgload (spotted
by OSSTest).

b_avgload is where we store the prediction of how
the load of a runqueue will look like in the medium
to long term, because of a vcpu being added to or
removed from there.

On vcpu removal, saturate down b_avgload to zero,
as it makes very few sense to predict that the
load of a runqueue will at some point become negative!

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
---
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/sched_credit2.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b92226c..1d79de0 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1323,14 +1323,16 @@ runq_assign(const struct scheduler *ops, struct vcpu *vc)
 static void
 __runq_deassign(struct csched2_vcpu *svc)
 {
+    struct csched2_runqueue_data *rqd = svc->rqd;
+
     ASSERT(!__vcpu_on_runq(svc));
     ASSERT(!(svc->flags & CSFLAG_scheduled));
 
     list_del_init(&svc->rqd_elem);
-    update_max_weight(svc->rqd, 0, svc->weight);
+    update_max_weight(rqd, 0, svc->weight);
 
     /* Expected new load based on removing this vcpu */
-    svc->rqd->b_avgload -= svc->avgload;
+    rqd->b_avgload = max_t(s_time_t, rqd->b_avgload - svc->avgload, 0);
 
     svc->rqd = NULL;
 }
@@ -1590,7 +1592,7 @@ csched2_cpu_pick(const struct scheduler *ops, struct vcpu *vc)
         if ( rqd == svc->rqd )
         {
             if ( cpumask_intersects(vc->cpu_hard_affinity, &rqd->active) )
-                rqd_avgload = rqd->b_avgload - svc->avgload;
+                rqd_avgload = max_t(s_time_t, rqd->b_avgload - svc->avgload, 0);
         }
         else if ( spin_trylock(&rqd->lock) )
         {


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

Re: [PATCH] xen: credit2: don't let b_avgload go negative.

[George Dunlap]

On 22/07/16 13:04, Dario Faggioli wrote:
> The ASSERT() made effective by b5b5876619bd8ec2e
> ("xen: credit2: fix two s_time_t handling issues
> in load balancing") triggers for b_avgload (spotted
> by OSSTest).
> 
> b_avgload is where we store the prediction of how
> the load of a runqueue will look like in the medium
> to long term, because of a vcpu being added to or
> removed from there.
> 
> On vcpu removal, saturate down b_avgload to zero,
> as it makes very few sense to predict that the
> load of a runqueue will at some point become negative!
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: George Dunlap <george.dunlap@citrix.com>

Wei, do you want to apply it?

Thanks,
 -George

> ---
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/sched_credit2.c |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index b92226c..1d79de0 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1323,14 +1323,16 @@ runq_assign(const struct scheduler *ops, struct vcpu *vc)
>  static void
>  __runq_deassign(struct csched2_vcpu *svc)
>  {
> +    struct csched2_runqueue_data *rqd = svc->rqd;
> +
>      ASSERT(!__vcpu_on_runq(svc));
>      ASSERT(!(svc->flags & CSFLAG_scheduled));
>  
>      list_del_init(&svc->rqd_elem);
> -    update_max_weight(svc->rqd, 0, svc->weight);
> +    update_max_weight(rqd, 0, svc->weight);
>  
>      /* Expected new load based on removing this vcpu */
> -    svc->rqd->b_avgload -= svc->avgload;
> +    rqd->b_avgload = max_t(s_time_t, rqd->b_avgload - svc->avgload, 0);
>  
>      svc->rqd = NULL;
>  }
> @@ -1590,7 +1592,7 @@ csched2_cpu_pick(const struct scheduler *ops, struct vcpu *vc)
>          if ( rqd == svc->rqd )
>          {
>              if ( cpumask_intersects(vc->cpu_hard_affinity, &rqd->active) )
> -                rqd_avgload = rqd->b_avgload - svc->avgload;
> +                rqd_avgload = max_t(s_time_t, rqd->b_avgload - svc->avgload, 0);
>          }
>          else if ( spin_trylock(&rqd->lock) )
>          {
> 


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

Re: [PATCH] xen: credit2: don't let b_avgload go negative.

[Wei Liu]

On Fri, Jul 22, 2016 at 01:34:27PM +0100, George Dunlap wrote:
> On 22/07/16 13:04, Dario Faggioli wrote:
> > The ASSERT() made effective by b5b5876619bd8ec2e
> > ("xen: credit2: fix two s_time_t handling issues
> > in load balancing") triggers for b_avgload (spotted
> > by OSSTest).
> > 
> > b_avgload is where we store the prediction of how
> > the load of a runqueue will look like in the medium
> > to long term, because of a vcpu being added to or
> > removed from there.
> > 
> > On vcpu removal, saturate down b_avgload to zero,
> > as it makes very few sense to predict that the
> > load of a runqueue will at some point become negative!
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Acked-by: George Dunlap <george.dunlap@citrix.com>
> 
> Wei, do you want to apply it?
> 

I will apply it with your ack.

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