Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1662423 > unrolled thread
| Started by | Vitaly Kuznetsov <vkuznets@redhat.com> |
|---|---|
| First post | 2017-06-09 15:30 +0200 |
| Last post | 2017-06-09 18:20 +0200 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.kernel
[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
| From | Vitaly Kuznetsov <vkuznets@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Vitaly Kuznetsov <vkuznets@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Vitaly Kuznetsov <vkuznets@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Vitaly Kuznetsov <vkuznets@redhat.com> |
|---|---|
| Date | 2017-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]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2017-06-09 18:10 +0200 |
| Subject | Re: [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]
| From | Stephen Hemminger <stephen@networkplumber.org> |
|---|---|
| Date | 2017-06-09 18:20 +0200 |
| Subject | Re: [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