This really should not happen, but:
1. it does happen! Some more info here:
http://lists.xen.org/archives/html/xen-devel/2016-06/msg00922.html
2. independently from 1, it makes sense and is easy enough
to have a 'safety catch'.
The reason why this is particularly bad for Credit2 is that
negative values of delta mean out of scale high load (because
of the conversion to unsigned). This, for instance in the
case of runqueue load, results in a runqueue having its load
updated to values of the order of 10000% or so, which in turns
means that the load balancer will migrate everything off from
the pCPUs in the runqueue, and leave them idle until the load
gets back to something sane... which may indeed take a while!
This is not a fix for the problem of time going backwards. In
fact, if that happens a lot, load tracking accuracy is still
compromized, but at least the effect is a lot less bad than
before.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
else
{
delta = now - rqd->load_last_update;
+ if ( unlikely(delta < 0) )
+ {
+ d2printk("%s: Time went backwards? now %"PRI_stime" llu %"PRI_stime"\n",
+ __func__, now, rqd->load_last_update);
+ delta = 0;
+ }
rqd->avgload =
( ( delta * ( (unsigned long long)rqd->load << prv->load_window_shift ) )
else
{
delta = now - svc->load_last_update;
+ if ( unlikely(delta < 0) )
+ {
+ d2printk("%s: Time went backwards? now %"PRI_stime" llu %"PRI_stime"\n",
+ __func__, now, svc->load_last_update);
+ delta = 0;
+ }
svc->avgload =
( ( delta * ( (unsigned long long)vcpu_load << prv->load_window_shift ) )