Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1662423 > unrolled thread

[PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Started byVitaly Kuznetsov <vkuznets@redhat.com>
First post2017-06-09 15:30 +0200
Last post2017-06-09 18:20 +0200
Articles 6 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements Vitaly Kuznetsov <vkuznets@redhat.com> - 2017-06-09 15:30 +0200
    [PATCH v8 02/10] x86/hyper-v: stash the max number of virtual/logical processor Vitaly Kuznetsov <vkuznets@redhat.com> - 2017-06-09 15:30 +0200
    [PATCH v8 09/10] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls Vitaly Kuznetsov <vkuznets@redhat.com> - 2017-06-09 15:40 +0200
    [PATCH v8 05/10] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT Vitaly Kuznetsov <vkuznets@redhat.com> - 2017-06-09 15:40 +0200
    Re: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and  hypercall improvements Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-09 18:10 +0200
    Re: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing  and hypercall improvements Stephen Hemminger <stephen@networkplumber.org> - 2017-06-09 18:20 +0200

#1662423 — [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

FromVitaly Kuznetsov <vkuznets@redhat.com>
Date2017-06-09 15:30 +0200
Subject[PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements
Message-ID<tQs9c-22p-11@gated-at.bofh.it>
Changes since v7:
- Minor code style fixes (drop explicit casting, reformat code a bit)
  in PATCH3 and PATCH9 [Andy Shevchenko]

Original description:

Hyper-V supports hypercalls for doing local and remote TLB flushing and
gives its guests hints when using hypercall is preferred. While doing
hypercalls for local TLB flushes is probably not practical (and is not
being suggested by modern Hyper-V versions) remote TLB flush with a
hypercall brings significant improvement.

To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
was creating 32 threads which were doing 100000 mmap/munmaps each on some
big file. Here are the results:

Before:
# time ./pthread_mmap ./randfile 
real	3m33.118s
user	0m3.698s
sys	3m16.624s

After:
# time ./pthread_mmap ./randfile 
real	2m19.920s
user	0m2.662s
sys	2m9.948s

This series brings a number of small improvements along the way: fast
hypercall implementation and using it for event signaling, rep hypercalls
implementation, hyperv tracing subsystem (which only traces the newly added
remote TLB flush for now).

Vitaly Kuznetsov (10):
  x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
  x86/hyper-v: stash the max number of virtual/logical processor
  x86/hyper-v: make hv_do_hypercall() inline
  x86/hyper-v: fast hypercall implementation
  hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
  x86/hyper-v: implement rep hypercalls
  hyper-v: globalize vp_index
  x86/hyper-v: use hypercall for remote TLB flush
  x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
  tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

 MAINTAINERS                         |   1 +
 arch/x86/Kbuild                     |   2 +-
 arch/x86/hyperv/Makefile            |   2 +-
 arch/x86/hyperv/hv_init.c           |  90 ++++++------
 arch/x86/hyperv/mmu.c               | 268 ++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/mshyperv.h     | 148 +++++++++++++++++++-
 arch/x86/include/asm/trace/hyperv.h |  38 +++++
 arch/x86/include/uapi/asm/hyperv.h  |  17 +++
 arch/x86/kernel/cpu/mshyperv.c      |  13 +-
 drivers/hv/channel_mgmt.c           |  20 +--
 drivers/hv/connection.c             |   7 +-
 drivers/hv/hv.c                     |   9 --
 drivers/hv/hyperv_vmbus.h           |  11 --
 drivers/hv/vmbus_drv.c              |  17 ---
 drivers/pci/host/pci-hyperv.c       |  10 +-
 include/linux/hyperv.h              |  17 +--
 16 files changed, 539 insertions(+), 131 deletions(-)
 create mode 100644 arch/x86/hyperv/mmu.c
 create mode 100644 arch/x86/include/asm/trace/hyperv.h

-- 
2.9.4

[toc] | [next] | [standalone]


#1662424 — [PATCH v8 02/10] x86/hyper-v: stash the max number of virtual/logical processor

FromVitaly Kuznetsov <vkuznets@redhat.com>
Date2017-06-09 15:30 +0200
Subject[PATCH v8 02/10] x86/hyper-v: stash the max number of virtual/logical processor
Message-ID<tQs9d-22p-37@gated-at.bofh.it>
In reply to#1662423
Max virtual processor will be needed for 'extended' hypercalls supporting
more than 64 vCPUs. While on it, unify on 'Hyper-V' in mshyperv.c as we
currently have a mix, report acquired misc features as well.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 arch/x86/include/asm/mshyperv.h |  2 ++
 arch/x86/kernel/cpu/mshyperv.c  | 12 +++++++++---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 66f9f2ac..115a0e2 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -29,6 +29,8 @@ struct ms_hyperv_info {
 	u32 features;
 	u32 misc_features;
 	u32 hints;
+	u32 max_vp_index;
+	u32 max_lp_index;
 };
 
 extern struct ms_hyperv_info ms_hyperv;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 04cb8d3..f259e01 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -175,9 +175,15 @@ static void __init ms_hyperv_init_platform(void)
 	ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
 	ms_hyperv.hints    = cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
 
-	pr_info("HyperV: features 0x%x, hints 0x%x\n",
+	pr_info("Hyper-V: features 0x%x, hints 0x%x\n",
 		ms_hyperv.features, ms_hyperv.hints);
 
+	ms_hyperv.max_vp_index = cpuid_eax(HVCPUID_IMPLEMENTATION_LIMITS);
+	ms_hyperv.max_lp_index = cpuid_ebx(HVCPUID_IMPLEMENTATION_LIMITS);
+
+	pr_debug("Hyper-V: max %u virtual processors, %u logical processors\n",
+		 ms_hyperv.max_vp_index, ms_hyperv.max_lp_index);
+
 	/*
 	 * Extract host information.
 	 */
@@ -203,7 +209,7 @@ static void __init ms_hyperv_init_platform(void)
 		rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
 		hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
 		lapic_timer_frequency = hv_lapic_frequency;
-		pr_info("HyperV: LAPIC Timer Frequency: %#x\n",
+		pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
 			lapic_timer_frequency);
 	}
 
@@ -237,7 +243,7 @@ static void __init ms_hyperv_init_platform(void)
 }
 
 const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
-	.name			= "Microsoft HyperV",
+	.name			= "Microsoft Hyper-V",
 	.detect			= ms_hyperv_platform,
 	.init_platform		= ms_hyperv_init_platform,
 };
-- 
2.9.4

[toc] | [prev] | [next] | [standalone]


#1662425 — [PATCH v8 09/10] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls

FromVitaly Kuznetsov <vkuznets@redhat.com>
Date2017-06-09 15:40 +0200
Subject[PATCH v8 09/10] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
Message-ID<tQsiR-25k-1@gated-at.bofh.it>
In reply to#1662423
Hyper-V hosts may support more than 64 vCPUs, we need to use
HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX hypercalls in this
case.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Changes since v7:
- Drop explicit casting from virt_to_phys() [Andy Shevchenko]
- Re-format max_gvas calculus [Andy Shevchenko]
---
 arch/x86/hyperv/mmu.c              | 130 ++++++++++++++++++++++++++++++++++++-
 arch/x86/include/uapi/asm/hyperv.h |  10 +++
 2 files changed, 138 insertions(+), 2 deletions(-)

diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index fe87ffe..0712111 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -16,11 +16,25 @@ struct hv_flush_pcpu {
 	u64 gva_list[];
 };
 
+/* HvFlushVirtualAddressSpaceEx, HvFlushVirtualAddressListEx hypercalls */
+struct hv_flush_pcpu_ex {
+	u64 address_space;
+	u64 flags;
+	struct {
+		u64 format;
+		u64 valid_bank_mask;
+		u64 bank_contents[];
+	} hv_vp_set;
+	u64 gva_list[];
+};
+
 /* Each gva in gva_list encodes up to 4096 pages to flush */
 #define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
 
 static struct hv_flush_pcpu __percpu *pcpu_flush;
 
+static struct hv_flush_pcpu_ex __percpu *pcpu_flush_ex;
+
 /*
  * Fills in gva_list starting from offset. Returns the number of items filled
  * in gva_list (including offset)
@@ -52,6 +66,34 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
 	return gva_n;
 }
 
+/* Return the number of banks in the resulting vp_set */
+static inline int cpumask_to_vp_set(struct hv_flush_pcpu_ex *flush,
+				    const struct cpumask *cpus)
+{
+	int cpu, vcpu, vcpu_bank, vcpu_offset, nr_bank = 1;
+
+	/*
+	 * Some banks may end up being empty but this is acceptable.
+	 */
+	for_each_cpu(cpu, cpus) {
+		vcpu = hv_cpu_number_to_vp_number(cpu);
+		vcpu_bank = vcpu / 64;
+		vcpu_offset = vcpu % 64;
+
+		/* valid_bank_mask can represent up to 64 banks */
+		if (vcpu_bank >= 64)
+			return 0;
+
+		__set_bit(vcpu_offset, (unsigned long *)
+			  &flush->hv_vp_set.bank_contents[vcpu_bank]);
+		if (vcpu_bank >= nr_bank)
+			nr_bank = vcpu_bank + 1;
+	}
+	flush->hv_vp_set.valid_bank_mask = GENMASK_ULL(nr_bank - 1, 0);
+
+	return nr_bank;
+}
+
 static void hyperv_flush_tlb_others(const struct cpumask *cpus,
 				    struct mm_struct *mm, unsigned long start,
 				    unsigned long end)
@@ -120,16 +162,100 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus,
 	native_flush_tlb_others(cpus, mm, start, end);
 }
 
+static void hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
+				       struct mm_struct *mm,
+				       unsigned long start,
+				       unsigned long end)
+{
+	int nr_bank = 0, max_gvas, gva_n;
+	struct hv_flush_pcpu_ex *flush;
+	u64 status = U64_MAX;
+	unsigned long flags;
+
+	if (!pcpu_flush_ex || !hv_hypercall_pg)
+		goto do_native;
+
+	if (cpumask_empty(cpus))
+		return;
+
+	local_irq_save(flags);
+
+	flush = this_cpu_ptr(pcpu_flush_ex);
+
+	if (mm) {
+		flush->address_space = virt_to_phys(mm->pgd);
+		flush->flags = 0;
+	} else {
+		flush->address_space = 0;
+		flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+	}
+
+	flush->hv_vp_set.valid_bank_mask = 0;
+
+	if (!cpumask_equal(cpus, cpu_present_mask)) {
+		flush->hv_vp_set.format = HV_GENERIC_SET_SPARCE_4K;
+		nr_bank = cpumask_to_vp_set(flush, cpus);
+	}
+
+	if (!nr_bank) {
+		flush->hv_vp_set.format = HV_GENERIC_SET_ALL;
+		flush->flags |= HV_FLUSH_ALL_PROCESSORS;
+	}
+
+	/*
+	 * We can flush not more than max_gvas with one hypercall. Flush the
+	 * whole address space if we were asked to do more.
+	 */
+	max_gvas =
+		(PAGE_SIZE - sizeof(*flush) - nr_bank *
+		 sizeof(flush->hv_vp_set.bank_contents[0])) /
+		sizeof(flush->gva_list[0]);
+
+	if (end == TLB_FLUSH_ALL) {
+		flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+		status = hv_do_rep_hypercall(
+			HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
+			0, nr_bank + 2, flush, NULL);
+	} else if (end && ((end - start)/HV_TLB_FLUSH_UNIT) > max_gvas) {
+		status = hv_do_rep_hypercall(
+			HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
+			0, nr_bank + 2, flush, NULL);
+	} else {
+		gva_n = fill_gva_list(flush->gva_list, nr_bank, start, end);
+		status = hv_do_rep_hypercall(
+			HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX,
+			gva_n, nr_bank + 2, flush, NULL);
+	}
+
+	local_irq_restore(flags);
+
+	if (!(status & HV_HYPERCALL_RESULT_MASK))
+		return;
+do_native:
+	native_flush_tlb_others(cpus, mm, start, end);
+}
+
 void hyperv_setup_mmu_ops(void)
 {
-	if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) {
+	if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED))
+		return;
+
+	if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
 		pr_info("Hyper-V: Using hypercall for remote TLB flush\n");
 		pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
+	} else {
+		pr_info("Hyper-V: Using ext hypercall for remote TLB flush\n");
+		pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others_ex;
 	}
 }
 
 void hyper_alloc_mmu(void)
 {
-	if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED)
+	if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED))
+		return;
+
+	if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
 		pcpu_flush = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
+	else
+		pcpu_flush_ex = __alloc_percpu(PAGE_SIZE, PAGE_SIZE);
 }
diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h
index cc0e70c..9a19272 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -152,6 +152,9 @@
  */
 #define HV_X64_DEPRECATING_AEOI_RECOMMENDED	(1 << 9)
 
+/* Recommend using the newer ExProcessorMasks interface */
+#define HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED	(1 << 11)
+
 /*
  * Crash notification flag.
  */
@@ -242,6 +245,8 @@
 #define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE	0x0002
 #define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST	0x0003
 #define HVCALL_NOTIFY_LONG_SPIN_WAIT		0x0008
+#define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX  0x0013
+#define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX   0x0014
 #define HVCALL_POST_MESSAGE			0x005c
 #define HVCALL_SIGNAL_EVENT			0x005d
 
@@ -263,6 +268,11 @@
 #define HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY	BIT(2)
 #define HV_FLUSH_USE_EXTENDED_RANGE_FORMAT	BIT(3)
 
+enum HV_GENERIC_SET_FORMAT {
+	HV_GENERIC_SET_SPARCE_4K,
+	HV_GENERIC_SET_ALL,
+};
+
 /* hypercall status code */
 #define HV_STATUS_SUCCESS			0
 #define HV_STATUS_INVALID_HYPERCALL_CODE	2
-- 
2.9.4

[toc] | [prev] | [next] | [standalone]


#1662428 — [PATCH v8 05/10] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT

FromVitaly Kuznetsov <vkuznets@redhat.com>
Date2017-06-09 15:40 +0200
Subject[PATCH v8 05/10] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
Message-ID<tQsiR-25k-9@gated-at.bofh.it>
In reply to#1662423
We need to pass only 8 bytes of input for HvSignalEvent which makes it a
perfect fit for fast hypercall. hv_input_signal_event_buffer is not needed
any more and hv_input_signal_event is converted to union for convenience.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 drivers/hv/channel_mgmt.c | 13 ++-----------
 drivers/hv/connection.c   |  2 +-
 include/linux/hyperv.h    | 15 +--------------
 3 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0fabd41..f501ce1 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -806,21 +806,12 @@ static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
 	/*
 	 * Setup state for signalling the host.
 	 */
-	newchannel->sig_event = (struct hv_input_signal_event *)
-				(ALIGN((unsigned long)
-				&newchannel->sig_buf,
-				HV_HYPERCALL_PARAM_ALIGN));
-
-	newchannel->sig_event->connectionid.asu32 = 0;
-	newchannel->sig_event->connectionid.u.id = VMBUS_EVENT_CONNECTION_ID;
-	newchannel->sig_event->flag_number = 0;
-	newchannel->sig_event->rsvdz = 0;
+	newchannel->sig_event = VMBUS_EVENT_CONNECTION_ID;
 
 	if (vmbus_proto_version != VERSION_WS2008) {
 		newchannel->is_dedicated_interrupt =
 				(offer->is_dedicated_interrupt != 0);
-		newchannel->sig_event->connectionid.u.id =
-				offer->connection_id;
+		newchannel->sig_event = offer->connection_id;
 	}
 
 	memcpy(&newchannel->offermsg, offer,
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 45e806e..37ecf51 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -408,6 +408,6 @@ void vmbus_set_event(struct vmbus_channel *channel)
 	if (!channel->is_dedicated_interrupt)
 		vmbus_send_interrupt(child_relid);
 
-	hv_do_hypercall(HVCALL_SIGNAL_EVENT, channel->sig_event, NULL);
+	hv_do_fast_hypercall8(HVCALL_SIGNAL_EVENT, channel->sig_event);
 }
 EXPORT_SYMBOL_GPL(vmbus_set_event);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index d1ae02d..2c9a2c8 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -677,18 +677,6 @@ union hv_connection_id {
 	} u;
 };
 
-/* Definition of the hv_signal_event hypercall input structure. */
-struct hv_input_signal_event {
-	union hv_connection_id connectionid;
-	u16 flag_number;
-	u16 rsvdz;
-};
-
-struct hv_input_signal_event_buffer {
-	u64 align8;
-	struct hv_input_signal_event event;
-};
-
 enum hv_numa_policy {
 	HV_BALANCED = 0,
 	HV_LOCALIZED,
@@ -771,8 +759,7 @@ struct vmbus_channel {
 	} callback_mode;
 
 	bool is_dedicated_interrupt;
-	struct hv_input_signal_event_buffer sig_buf;
-	struct hv_input_signal_event *sig_event;
+	u64 sig_event;
 
 	/*
 	 * Starting with win8, this field will be used to specify
-- 
2.9.4

[toc] | [prev] | [next] | [standalone]


#1662590 — Re: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-06-09 18:10 +0200
SubjectRe: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements
Message-ID<tQuE2-3IK-41@gated-at.bofh.it>
In reply to#1662423
On Fri, Jun 9, 2017 at 4:27 PM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> Changes since v7:
> - Minor code style fixes (drop explicit casting, reformat code a bit)
>   in PATCH3 and PATCH9 [Andy Shevchenko]
>
> Original description:
>
> Hyper-V supports hypercalls for doing local and remote TLB flushing and
> gives its guests hints when using hypercall is preferred. While doing
> hypercalls for local TLB flushes is probably not practical (and is not
> being suggested by modern Hyper-V versions) remote TLB flush with a
> hypercall brings significant improvement.
>
> To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
> was creating 32 threads which were doing 100000 mmap/munmaps each on some
> big file. Here are the results:
>
> Before:
> # time ./pthread_mmap ./randfile
> real    3m33.118s
> user    0m3.698s
> sys     3m16.624s
>
> After:
> # time ./pthread_mmap ./randfile
> real    2m19.920s
> user    0m2.662s
> sys     2m9.948s
>
> This series brings a number of small improvements along the way: fast
> hypercall implementation and using it for event signaling, rep hypercalls
> implementation, hyperv tracing subsystem (which only traces the newly added
> remote TLB flush for now).
>

FWIW,

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

to the patches that do not have it yet.

> Vitaly Kuznetsov (10):
>   x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
>   x86/hyper-v: stash the max number of virtual/logical processor
>   x86/hyper-v: make hv_do_hypercall() inline
>   x86/hyper-v: fast hypercall implementation
>   hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
>   x86/hyper-v: implement rep hypercalls
>   hyper-v: globalize vp_index
>   x86/hyper-v: use hypercall for remote TLB flush
>   x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
>   tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
>
>  MAINTAINERS                         |   1 +
>  arch/x86/Kbuild                     |   2 +-
>  arch/x86/hyperv/Makefile            |   2 +-
>  arch/x86/hyperv/hv_init.c           |  90 ++++++------
>  arch/x86/hyperv/mmu.c               | 268 ++++++++++++++++++++++++++++++++++++
>  arch/x86/include/asm/mshyperv.h     | 148 +++++++++++++++++++-
>  arch/x86/include/asm/trace/hyperv.h |  38 +++++
>  arch/x86/include/uapi/asm/hyperv.h  |  17 +++
>  arch/x86/kernel/cpu/mshyperv.c      |  13 +-
>  drivers/hv/channel_mgmt.c           |  20 +--
>  drivers/hv/connection.c             |   7 +-
>  drivers/hv/hv.c                     |   9 --
>  drivers/hv/hyperv_vmbus.h           |  11 --
>  drivers/hv/vmbus_drv.c              |  17 ---
>  drivers/pci/host/pci-hyperv.c       |  10 +-
>  include/linux/hyperv.h              |  17 +--
>  16 files changed, 539 insertions(+), 131 deletions(-)
>  create mode 100644 arch/x86/hyperv/mmu.c
>  create mode 100644 arch/x86/include/asm/trace/hyperv.h
>
> --
> 2.9.4
>



-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]


#1662598 — Re: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

FromStephen Hemminger <stephen@networkplumber.org>
Date2017-06-09 18:20 +0200
SubjectRe: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements
Message-ID<tQuNI-3M7-17@gated-at.bofh.it>
In reply to#1662423
On Fri,  9 Jun 2017 15:27:26 +0200
Vitaly Kuznetsov <vkuznets@redhat.com> wrote:

> Changes since v7:
> - Minor code style fixes (drop explicit casting, reformat code a bit)
>   in PATCH3 and PATCH9 [Andy Shevchenko]
> 
> Original description:
> 
> Hyper-V supports hypercalls for doing local and remote TLB flushing and
> gives its guests hints when using hypercall is preferred. While doing
> hypercalls for local TLB flushes is probably not practical (and is not
> being suggested by modern Hyper-V versions) remote TLB flush with a
> hypercall brings significant improvement.
> 
> To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
> was creating 32 threads which were doing 100000 mmap/munmaps each on some
> big file. Here are the results:
> 
> Before:
> # time ./pthread_mmap ./randfile 
> real	3m33.118s
> user	0m3.698s
> sys	3m16.624s
> 
> After:
> # time ./pthread_mmap ./randfile 
> real	2m19.920s
> user	0m2.662s
> sys	2m9.948s
> 
> This series brings a number of small improvements along the way: fast
> hypercall implementation and using it for event signaling, rep hypercalls
> implementation, hyperv tracing subsystem (which only traces the newly added
> remote TLB flush for now).
> 
> Vitaly Kuznetsov (10):
>   x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
>   x86/hyper-v: stash the max number of virtual/logical processor
>   x86/hyper-v: make hv_do_hypercall() inline
>   x86/hyper-v: fast hypercall implementation
>   hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
>   x86/hyper-v: implement rep hypercalls
>   hyper-v: globalize vp_index
>   x86/hyper-v: use hypercall for remote TLB flush
>   x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
>   tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
> 
>  MAINTAINERS                         |   1 +
>  arch/x86/Kbuild                     |   2 +-
>  arch/x86/hyperv/Makefile            |   2 +-
>  arch/x86/hyperv/hv_init.c           |  90 ++++++------
>  arch/x86/hyperv/mmu.c               | 268 ++++++++++++++++++++++++++++++++++++
>  arch/x86/include/asm/mshyperv.h     | 148 +++++++++++++++++++-
>  arch/x86/include/asm/trace/hyperv.h |  38 +++++
>  arch/x86/include/uapi/asm/hyperv.h  |  17 +++
>  arch/x86/kernel/cpu/mshyperv.c      |  13 +-
>  drivers/hv/channel_mgmt.c           |  20 +--
>  drivers/hv/connection.c             |   7 +-
>  drivers/hv/hv.c                     |   9 --
>  drivers/hv/hyperv_vmbus.h           |  11 --
>  drivers/hv/vmbus_drv.c              |  17 ---
>  drivers/pci/host/pci-hyperv.c       |  10 +-
>  include/linux/hyperv.h              |  17 +--
>  16 files changed, 539 insertions(+), 131 deletions(-)
>  create mode 100644 arch/x86/hyperv/mmu.c
>  create mode 100644 arch/x86/include/asm/trace/hyperv.h
> 

Looks good.

Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web