Credit2 has different cpus share a lock; which means that as cpus are added,
and as they're moved between pools, the pointer to the scheduler lock may also
change as well.
Since we don't want to have to grab a lock before grabbing the per-cpu
scheduler lock,
we use the lock itself to protect against the pointer changing.
However, since it may change between reading and locking, after we grab the
lock we
need to check to make sure it's still the right one.
Update the vcpu_schedule_lock() definition to reflect this: both v->processor
and
that processor's schedule lock are liable to change; check both after grabbing
the lock, and release / re-acquire if necessary.
Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxx>
diff -r 42291c2cebf1 -r b4be3457d8bd xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h Thu Dec 23 12:23:56 2010 +0000
+++ b/xen/include/xen/sched-if.h Thu Dec 23 12:24:10 2010 +0000
@@ -41,23 +41,25 @@
static inline void vcpu_schedule_lock(struct vcpu *v)
{
- unsigned int cpu;
+ spinlock_t * lock;
for ( ; ; )
{
- /* NB: For schedulers with multiple cores per runqueue,
- * a vcpu may change processor w/o changing runqueues;
- * so we may release a lock only to grab it again.
+ /* v->processor may change when grabbing the lock; but
+ * per_cpu(v->processor) may also change, if changing
+ * cpu pool also changes the scheduler lock. Retry
+ * until they match.
*
- * If that is measured to be an issue, then the check
- * should be changed to checking if the locks pointed to
- * by cpu and v->processor are still the same.
+ * It may also be the case that v->processor may change
+ * but the lock may be the same; this will succeed
+ * in that case.
*/
- cpu = v->processor;
- spin_lock(per_cpu(schedule_data, cpu).schedule_lock);
- if ( likely(v->processor == cpu) )
+ lock=per_cpu(schedule_data, v->processor).schedule_lock;
+
+ spin_lock(lock);
+ if ( likely(lock == per_cpu(schedule_data,
v->processor).schedule_lock) )
break;
- spin_unlock(per_cpu(schedule_data, cpu).schedule_lock);
+ spin_unlock(lock);
}
}
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home