date:20170523

[Xen-devel] [PATCH v3 3/3] VT-d PI: restrict the vcpu number on a given pcpu

2017-05-23 Thread Chao Gao

Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
too many vCPUs are blocked on a given pCPU, it will incur that the list
grows too long. After a simple analysis, there are 32k domains and
128 vcpu per domain, thus about 4M vCPUs may be blocked in one pCPU's
PI blocking list. When a wakeup interrupt arrives, the list is
traversed to find some specific vCPUs to wake them up. This traversal in
that case would consume much time.

To mitigate this issue, this patch limits the vcpu number on a given
pCPU, taking factors such as perfomance of common case, current hvm vcpu
count and current pcpu count into consideration. With this method, for
the common case, it works fast and for some extreme cases, the list
length is under control.

The change in vmx_pi_unblock_vcpu() is for the following case:
vcpu is running -> try to block (this patch may change NSDT to
another pCPU) but notification comes in time, thus the vcpu
goes back to running station -> VM-entry (we should set NSDT again,
reverting the change we make to NSDT in vmx_vcpu_block())

Signed-off-by: Chao Gao 
---
 xen/arch/x86/hvm/vmx/vmx.c | 70 +-
 1 file changed, 63 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index abbf16b..91ee65b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -100,16 +100,62 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
 spin_lock_init(&per_cpu(vmx_pi_blocking, cpu).lock);
 }
 
+/*
+ * By default, the local pcpu (means the one the vcpu is currently running on)
+ * is chosen as the destination of wakeup interrupt. But if the vcpu number of
+ * the pcpu exceeds a limit, another pcpu is chosen until we find a suitable
+ * one.
+ *
+ * Currently, choose (v_tot/p_tot) + K as the limit of vcpu count, where
+ * v_tot is the total number of hvm vcpus on the system, p_tot is the total
+ * number of pcpus in the system, and K is a fixed number. Experments shows
+ * the maximum time to wakeup a vcpu from a 128-entry blocking list is about
+ * 22us, which is tolerable. So choose 128 as the fixed number K.
+ *
+ * This policy makes sure:
+ * 1) for common cases, the limit won't be reached and the local pcpu is used
+ * which is beneficial to performance (at least, avoid an IPI when unblocking
+ * vcpu).
+ * 2) for the worst case, the blocking list length scales with the vcpu count
+ * divided by the pcpu count.
+ */
+#define PI_LIST_FIXED_NUM 128
+#define PI_LIST_LIMIT (atomic_read(&num_hvm_vcpus) / num_online_cpus() + \
+   PI_LIST_FIXED_NUM)
+
+static bool pi_over_limit(int count)
+{
+/* Compare w/ constant first to save an atomic read in the common case */
+return ((count > PI_LIST_FIXED_NUM) &&
+(count > (atomic_read(&num_hvm_vcpus) / num_online_cpus()) +
+PI_LIST_FIXED_NUM));
+}
+
 static void vmx_vcpu_block(struct vcpu *v)
 {
 unsigned long flags;
-unsigned int dest;
+unsigned int dest, pi_cpu;
 spinlock_t *old_lock;
-spinlock_t *pi_blocking_list_lock =
-   &per_cpu(vmx_pi_blocking, v->processor).lock;
 struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
+spinlock_t *pi_blocking_list_lock;
+
+pi_cpu = v->processor;
+ retry:
+pi_blocking_list_lock = &per_cpu(vmx_pi_blocking, pi_cpu).lock;
 
 spin_lock_irqsave(pi_blocking_list_lock, flags);
+/*
+ * Since pi_cpu may now be one other than the one v is currently
+ * running on, check to make sure that it's still up.
+ */
+if ( unlikely((!cpu_online(pi_cpu)) ||
+ pi_over_limit(per_cpu(vmx_pi_blocking, pi_cpu).counter)) )
+{
+pi_cpu = cpumask_cycle(pi_cpu, &cpu_online_map);
+spin_unlock_irqrestore(pi_blocking_list_lock, flags);
+goto retry;
+}
+
 old_lock = cmpxchg(&v->arch.hvm_vmx.pi_blocking.lock, NULL,
pi_blocking_list_lock);
 
@@ -120,11 +166,11 @@ static void vmx_vcpu_block(struct vcpu *v)
  */
 ASSERT(old_lock == NULL);
 
-per_cpu(vmx_pi_blocking, v->processor).counter++;
-TRACE_4D(TRC_HVM_PI_LIST_ADD, v->domain->domain_id, v->vcpu_id,
- v->processor, per_cpu(vmx_pi_blocking, v->processor).counter);
+per_cpu(vmx_pi_blocking, pi_cpu).counter++;
+TRACE_4D(TRC_HVM_PI_LIST_ADD, v->domain->domain_id, v->vcpu_id, pi_cpu,
+ per_cpu(vmx_pi_blocking, pi_cpu).counter);
 list_add_tail(&v->arch.hvm_vmx.pi_blocking.list,
-  &per_cpu(vmx_pi_blocking, v->processor).list);
+  &per_cpu(vmx_pi_blocking, pi_cpu).list);
 spin_unlock_irqrestore(pi_blocking_list_lock, flags);
 
 ASSERT(!pi_test_sn(pi_desc));
@@ -134,6 +180,13 @@ static void vmx_vcpu_block(struct vcpu *v)
 ASSERT(pi_desc->ndst ==
(x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK)));
 
+if ( unlikely(pi_cpu != v->processor) )
+{
+dest = cpu_physical_id(pi_cpu);
+

[Xen-devel] [PATCH v3] VT-d PI: track the vcpu number in pi blocking list

2017-05-23 Thread Chao Gao

This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track
how many entries are on the pi blocking list. In order to analyze list
operation frequence and obtain the list length, add some relevant events
to xentrace and some associated code in xenalyze. As to xenalyze, for
removing from pi list can happen in various contexts (interrupt context,
and non-interrupt context) and be done by the vcpu itself or others, some of
the contexts would incur that toplevel_assert_check() fails. To bypass this
check, this patch adds a new type TRC_HVM_ASYNC and for this new type event,
the context would not be checked.

Signed-off-by: Chao Gao 
---
 tools/xentrace/formats  |   3 +
 tools/xentrace/xenalyze.c   | 154 +---
 xen/arch/x86/hvm/vmx/vmx.c  |  33 +++--
 xen/include/asm-x86/hvm/trace.h |   1 +
 xen/include/public/trace.h  |   5 ++
 5 files changed, 182 insertions(+), 14 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 8b31780..54e0b11 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -125,6 +125,9 @@
 0x00082020  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  INTR_WINDOW [ value = 
0x%(1)08x ]
 0x00082021  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  NPF [ gpa = 
0x%(2)08x%(1)08x mfn = 0x%(4)08x%(3)08x qual = 0x%(5)04x p2mt = 0x%(6)04x ]
 0x00082023  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  TRAP[ vector = 
0x%(1)02x ]
+0x00082026  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  PI_LIST_ADD [ domid = 
0x%(1)04x vcpu = 0x%(2)04x, pcpu = 0x%(3)04x, #entry = 0x%(4)04x ]
+
+0x00088001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  ASYNC_PI_LIST_DEL [ domid = 
0x%(1)04x vcpu = 0x%(2)04x ]
 
 0x0010f001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  page_grant_map  [ domid = 
%(1)d ]
 0x0010f002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  page_grant_unmap[ domid = 
%(1)d ]
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index fa608ad..fbc2429 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -296,6 +296,7 @@ struct symbol_struct {
 };
 
 void error(enum error_level l, struct record_info *ri);
+struct vcpu_data * vcpu_find(int did, int vid);
 
 void parse_symbol_file(char *fn) {
 unsigned long long last_addr = 0;
@@ -944,6 +945,7 @@ enum {
 HVM_EVENT_TRAP,
 HVM_EVENT_TRAP_DEBUG,
 HVM_EVENT_VLAPIC,
+HVM_EVENT_PI_LIST_ADD,
 HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
@@ -979,13 +981,15 @@ char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
 "realmode_emulate",
 "trap",
 "trap_debug",
-"vlapic"
+"vlapic",
+"pi_list_add",
 };
 
 enum {
 HVM_VOL_VMENTRY,
 HVM_VOL_VMEXIT,
 HVM_VOL_HANDLER,
+HVM_VOL_ASYNC,
 HVM_VOL_MAX
 };
 
@@ -1012,6 +1016,7 @@ char *hvm_vol_name[HVM_VOL_MAX] = {
 [HVM_VOL_VMENTRY]="vmentry",
 [HVM_VOL_VMEXIT] ="vmexit",
 [HVM_VOL_HANDLER]="handler",
+[HVM_VOL_ASYNC]="async",
 };
 
 enum {
@@ -1337,6 +1342,9 @@ struct hvm_data {
 struct {
 struct io_address *mmio, *pio;
 } io;
+struct {
+int pi_list_add, pi_list_del;
+} pi;
 } summary;
 
 /* In-flight accumulation information */
@@ -1391,6 +1399,9 @@ struct hvm_data {
 
 /* Historical info */
 tsc_t last_rdtsc;
+
+/* Destination pcpu of posted interrupt's wakeup interrupt */
+int pi_cpu;
 };
 
 enum {
@@ -1457,6 +1468,8 @@ void init_hvm_data(struct hvm_data *h, struct vcpu_data 
*v) {
 }
 for(i=0; isummary.guest_interrupt[i].count=0;
+
+h->pi_cpu = -1;
 }
 
 /* PV data */
@@ -1766,6 +1779,14 @@ char * toplevel_name[TOPLEVEL_MAX] = {
 [TOPLEVEL_HW]="hw",
 };
 
+enum {
+SUBLEVEL_HVM_ENTRYEXIT=1,
+SUBLEVEL_HVM_HANDLER,
+SUBLEVEL_HVM_EMUL,
+SUBLEVEL_HVM_ASYNC,
+SUBLEVEL_HVM_MAX=SUBLEVEL_HVM_ASYNC+1,
+};
+
 struct trace_volume {
 unsigned long long toplevel[TOPLEVEL_MAX];
 unsigned long long sched_verbose;
@@ -1852,6 +1873,9 @@ struct pcpu_info {
 tsc_t tsc;
 struct cycle_summary idle, running, lost;
 } time;
+
+/* Posted Interrupt List Length */
+int pi_list_length;
 };
 
 void __fill_in_record_info(struct pcpu_info *p);
@@ -4726,6 +4750,71 @@ void hvm_generic_dump(struct record_info *ri, char * 
prefix)
 printf(" ]\n");
 }
 
+void hvm_pi_list_add_process(struct record_info *ri, struct hvm_data *h)
+{
+struct {
+int did;
+int vid;
+int pcpu;
+int len;
+} *data;
+struct vcpu_data *v;
+
+data = (typeof(data))ri->rec.u.tsc.data;
+v = vcpu_find(data->did, data->vid);
+if ( !v->hvm.init )
+init_hvm_data(&v->hvm, v);
+
+if ( opt.dump_all )
+printf("d%uv%u is added to pi blocking list of pcpu%u. "
+   "The list length is now %d\n",
+   data->did, data->vid, data->pcpu, data->len);
+
+v->hvm.pi_cpu = data->pcpu;
+v->hvm.summary.pi.pi_list_add++;
+if ( data->p

[Xen-devel] [PATCH v3 2/3] vcpu: track hvm vcpu number on the system

2017-05-23 Thread Chao Gao

This number is used to calculate how many hvm vcpu on a pcpu on average.
This counting is x86 specific.

Signed-off-by: Chao Gao 
---
 xen/arch/x86/domain.c| 10 ++
 xen/include/asm-x86/domain.h |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 13cdc50..050fe0e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -66,6 +66,9 @@
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
+/* how many hvm vcpu on this system? */
+atomic_t num_hvm_vcpus;
+
 static void default_idle(void);
 void (*pm_idle) (void) __read_mostly = default_idle;
 void (*dead_idle) (void) __read_mostly = default_dead_idle;
@@ -467,7 +470,11 @@ int vcpu_initialise(struct vcpu *v)
 xfree(v->arch.pv_vcpu.trap_ctxt);
 }
 else if ( !is_idle_domain(v->domain) )
+{
 vpmu_initialise(v);
+if ( is_hvm_domain(v->domain) )
+atomic_inc(&num_hvm_vcpus);
+}
 
 return rc;
 }
@@ -489,7 +496,10 @@ void vcpu_destroy(struct vcpu *v)
 vpmu_destroy(v);
 
 if ( is_hvm_vcpu(v) )
+{
 hvm_vcpu_destroy(v);
+atomic_dec(&num_hvm_vcpus);
+}
 else
 xfree(v->arch.pv_vcpu.trap_ctxt);
 }
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 924caac..769cde2 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -31,6 +31,8 @@
 #define nmi_pendingnmi_state.pending
 #define mce_pendingmce_state.pending
 
+extern atomic_t num_hvm_vcpus;
+
 struct trap_bounce {
 uint32_t  error_code;
 uint8_t   flags; /* TBF_ */
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 0/3] mitigate the per-pCPU blocking list may be too long

2017-05-23 Thread Chao Gao

VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU
on a given pCPU. Theoretically, there are 32K domain on single host,
128 vCPUs per domain. If all vCPUs are blocked on the same pCPU,
4M vCPUs are in the same list. Traversing this list consumes too
much time. More discussion can be found in [1,2,3].

To mitigate this issue, this series put vcpus to another pcpu's list
when the local pcpu's list length reachs an upper bound. The upper
bound is determined by total vcpu count and total pcpu count in the
system.

PATCH 1/3 adds a counter to track the per-pCPU blocking list's length
and to aid analysis and obtain the list length, add some relevant
events to xentrace. With this patch, some data can be acquired to help
to validate patch 3/3.

PATCH 2/3 uses a global variable to track how many hvm vcpus on this
system. It is used to calculate the number limit of blocked vcpu on a
given pcpu.

In patch 3/3, a policy is used to restrict the vcpu count on a given
pcpu's pi blocking list in case the list grows too long.

In this new version, the method only putting vcpus which are referred
by at least one IRTE to the list is removed for
1. The implementation is intrusive.
2. Now, no evidence shows its necessity.

[1]
https://lists.gt.net/xen/devel/422661?search_string=VT-d%20posted-interrupt%20core%20logic%20handling;#422661
[2]
https://lists.gt.net/xen/devel/422567?search_string=%20The%20length%20of%20the%20list%20depends;#422567
[3]
https://lists.gt.net/xen/devel/472749?search_string=enable%20vt-d%20pi%20by%20default;#472749

Chao Gao (3):
VT-d PI: track the vcpu number in pi blocking list
vcpu: track hvm vcpu number on the system
VT-d PI: restrict the vcpu number on a given pcpu

1 2 >

1 - 100 of 130 matches

Mail list logo