Currently, when pinning vcpus, the target vcpu is migrated to the first
bit in the new cpumask even if the vcpu''s current process is included
in
the new mask. This produces a non-obvious side-effect when pinning
vcpus.
[x460-3 ~]# xm vcpu-list 5
Name ID VCPU CPU State Time(s) CPU Affinity
x460-3-guest 5 0 31 -b- 4.2 any cpu
[x460-3 ~]# xm vcpu-list 5
[x460-3 ~]# xm vcpu-pin 5 0 28-31
[x460-3 ~]# xm vcpu-list 5
Name ID VCPU CPU State Time(s) CPU Affinity
x460-3-guest 5 0 28 -b- 4.2 28-31
This patch adds a check to determine if a vcpu needs to switch
processors during a pin operation, removing the above side-effect.
[x460-3 ~]# xm vcpu-list 2
Name ID VCPU CPU State Time(s) CPU Affinity
x460-3-guest 2 0 31 -b- 4.2 any cpu
[x460-3 ~]# xm vcpu-pin 2 0 28-31
Name ID VCPU CPU State Time(s) CPU Affinity
x460-3-guest 2 0 31 -b- 4.2 28-31
[x460-3 ~]# xm vcpu-pin 2 0 28-30
[x460-3 ~]# xm vcpu-list 2
Name ID VCPU CPU State Time(s) CPU Affinity
x460-3-guest 2 0 28 -b- 4.2 28-30
Tested on sedf scheduler.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
diffstat output:
sched_bvt.c | 14 ++++++++++----
sched_sedf.c | 12 +++++++++---
2 files changed, 19 insertions(+), 7 deletions(-)
---
# HG changeset patch
# User rharper@x460-3
# Node ID ffa67b655a8f5855549880a0733c7fae6b86f3ae
# Parent ad686e96536fe8c9318efa80e777d5c2555f2682
When setting a vcpu''s affinity via pin operations, only
migrate the vcpu if its current processor is not in the
new affinity mask.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
diff -r ad686e96536f -r ffa67b655a8f xen/common/sched_bvt.c
--- a/xen/common/sched_bvt.c Sat Apr 15 04:17:27 2006
+++ b/xen/common/sched_bvt.c Sat Apr 15 05:12:00 2006
@@ -287,11 +287,17 @@
if ( v == current )
return cpu_isset(v->processor, *affinity) ? 0 : -EBUSY;
- vcpu_pause(v);
+ /*
+ * only migrate the vcpu if the vcpu''s processor is not in
+ * the new cpumask_t
+ */
+ if ( !cpu_isset(v->processor, *affinity) ) {
+ vcpu_pause(v);
+ v->processor = first_cpu(*affinity);
+ EBVT_INFO(v)->migrated = 1;
+ vcpu_unpause(v);
+ }
v->cpu_affinity = *affinity;
- v->processor = first_cpu(v->cpu_affinity);
- EBVT_INFO(v)->migrated = 1;
- vcpu_unpause(v);
return 0;
}
diff -r ad686e96536f -r ffa67b655a8f xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c Sat Apr 15 04:17:27 2006
+++ b/xen/common/sched_sedf.c Sat Apr 15 05:12:00 2006
@@ -1186,10 +1186,16 @@
if ( v == current )
return cpu_isset(v->processor, *affinity) ? 0 : -EBUSY;
- vcpu_pause(v);
+ /*
+ * only migrate the vcpu if the vcpu''s processor is not in
+ * the new cpumask_t
+ */
+ if ( !cpu_isset(v->processor,*affinity) ) {
+ vcpu_pause(v);
+ v->processor = first_cpu(*affinity);
+ vcpu_unpause(v);
+ }
v->cpu_affinity = *affinity;
- v->processor = first_cpu(v->cpu_affinity);
- vcpu_unpause(v);
return 0;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2006-Apr-15 09:10 UTC
Re: [Xen-devel] [PATCH] xen: migrate vcpus only when needed
> Currently, when pinning vcpus, the target vcpu is migrated to the first > bit in the new cpumask even if the vcpu''s current process is included in > the new mask. This produces a non-obvious side-effect when pinning > vcpus.How is that non-obvious? You specify a set of CPUs on which you are happy for that VCPU to run and Xen may run the VCPU on any of those CPUs at any time. The current implementation''s decision to change the CPU binding the moment you specify the set of CPUs, and always choose the lowest one, is perfectly reasonable given the specification of that interface. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel