* Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Quan Xu @ 2017-11-14 8:15 UTC (permalink / raw)
To: Wanpeng Li
Cc: Juergen Gross, Yang Zhang, Rusty Russell, kvm, linux-doc,
the arch/x86 maintainers, linux-kernel@vger.kernel.org,
virtualization, Ingo Molnar, Quan Xu, H. Peter Anvin,
open list:FILESYSTEMS (VFS and infrastructure), xen-devel,
Alok Kataria, Thomas Gleixner
In-Reply-To: <CANRm+CxirO0aSAQnOfPG0+KPCOnXf3SEASwBiprLmtncZE53pA@mail.gmail.com>
On 2017/11/14 15:12, Wanpeng Li wrote:
> 2017-11-14 15:02 GMT+08:00 Quan Xu <quan.xu0@gmail.com>:
>>
>> On 2017/11/13 18:53, Juergen Gross wrote:
>>> On 13/11/17 11:06, Quan Xu wrote:
>>>> From: Quan Xu <quan.xu0@gmail.com>
>>>>
>>>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
>>>> in idle path which will poll for a while before we enter the real idle
>>>> state.
>>>>
>>>> In virtualization, idle path includes several heavy operations
>>>> includes timer access(LAPIC timer or TSC deadline timer) which will
>>>> hurt performance especially for latency intensive workload like message
>>>> passing task. The cost is mainly from the vmexit which is a hardware
>>>> context switch between virtual machine and hypervisor. Our solution is
>>>> to poll for a while and do not enter real idle path if we can get the
>>>> schedule event during polling.
>>>>
>>>> Poll may cause the CPU waste so we adopt a smart polling mechanism to
>>>> reduce the useless poll.
>>>>
>>>> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
>>>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>>>> Cc: Juergen Gross <jgross@suse.com>
>>>> Cc: Alok Kataria <akataria@vmware.com>
>>>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>> Cc: Ingo Molnar <mingo@redhat.com>
>>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>>> Cc: x86@kernel.org
>>>> Cc: virtualization@lists.linux-foundation.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: xen-devel@lists.xenproject.org
>>> Hmm, is the idle entry path really so critical to performance that a new
>>> pvops function is necessary?
>> Juergen, Here is the data we get when running benchmark netperf:
>> 1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
>> 29031.6 bit/s -- 76.1 %CPU
>>
>> 2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
>> 35787.7 bit/s -- 129.4 %CPU
>>
>> 3. w/ kvm dynamic poll:
>> 35735.6 bit/s -- 200.0 %CPU
> Actually we can reduce the CPU utilization by sleeping a period of
> time as what has already been done in the poll logic of IO subsystem,
> then we can improve the algorithm in kvm instead of introduing another
> duplicate one in the kvm guest.
We really appreciate upstream's kvm dynamic poll mechanism, which is
really helpful for a lot of scenario..
However, as description said, in virtualization, idle path includes
several heavy operations includes timer access (LAPIC timer or TSC
deadline timer) which will hurt performance especially for latency
intensive workload like message passing task. The cost is mainly from
the vmexit which is a hardware context switch between virtual machine
and hypervisor.
for upstream's kvm dynamic poll mechanism, even you could provide a
better algorism, how could you bypass timer access (LAPIC timer or TSC
deadline timer), or a hardware context switch between virtual machine
and hypervisor. I know these is a tradeoff.
Furthermore, here is the data we get when running benchmark contextswitch
to measure the latency(lower is better):
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
3402.9 ns/ctxsw -- 199.8 %CPU
2. w/ patch and disable kvm dynamic poll:
1163.5 ns/ctxsw -- 205.5 %CPU
3. w/ kvm dynamic poll:
2280.6 ns/ctxsw -- 199.5 %CPU
so, these tow solution are quite similar, but not duplicate..
that's also why to add a generic idle poll before enter real idle path.
When a reschedule event is pending, we can bypass the real idle path.
Quan
Alibaba Cloud
> Regards,
> Wanpeng Li
>
>> 4. w/patch and w/ kvm dynamic poll:
>> 42225.3 bit/s -- 198.7 %CPU
>>
>> 5. idle=poll
>> 37081.7 bit/s -- 998.1 %CPU
>>
>>
>>
>> w/ this patch, we will improve performance by 23%.. even we could improve
>> performance by 45.4%, if we use w/patch and w/ kvm dynamic poll. also the
>> cost of CPU is much lower than 'idle=poll' case..
>>
>>> Wouldn't a function pointer, maybe guarded
>>> by a static key, be enough? A further advantage would be that this would
>>> work on other architectures, too.
>>
>> I assume this feature will be ported to other archs.. a new pvops makes code
>> clean and easy to maintain. also I tried to add it into existed pvops, but
>> it
>> doesn't match.
>>
>>
>>
>> Quan
>> Alibaba Cloud
>>>
>>> Juergen
>>>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll
From: Ingo Molnar @ 2017-11-14 7:44 UTC (permalink / raw)
To: Quan Xu
Cc: Yang Zhang, Quan Xu, kvm, linux-doc, x86, linux-kernel,
virtualization, linux-fsdevel
In-Reply-To: <35da8c93-95fb-8bf0-8538-4e1ef5f126f4@gmail.com>
* Quan Xu <quan.xu0@gmail.com> wrote:
>
>
> On 2017/11/13 23:08, Ingo Molnar wrote:
> > * Quan Xu <quan.xu04@gmail.com> wrote:
> >
> > > From: Quan Xu <quan.xu0@gmail.com>
> > >
> > > To reduce the cost of poll, we introduce three sysctl to control the
> > > poll time when running as a virtual machine with paravirt.
> > >
> > > Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
> > > Signed-off-by: Quan Xu <quan.xu0@gmail.com>
> > > ---
> > > Documentation/sysctl/kernel.txt | 35 +++++++++++++++++++++++++++++++++++
> > > arch/x86/kernel/paravirt.c | 4 ++++
> > > include/linux/kernel.h | 6 ++++++
> > > kernel/sysctl.c | 34 ++++++++++++++++++++++++++++++++++
> > > 4 files changed, 79 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> > > index 694968c..30c25fb 100644
> > > --- a/Documentation/sysctl/kernel.txt
> > > +++ b/Documentation/sysctl/kernel.txt
> > > @@ -714,6 +714,41 @@ kernel tries to allocate a number starting from this one.
> > > ==============================================================
> > > +paravirt_poll_grow: (X86 only)
> > > +
> > > +Multiplied value to increase the poll time. This is expected to take
> > > +effect only when running as a virtual machine with CONFIG_PARAVIRT
> > > +enabled. This can't bring any benifit on bare mental even with
> > > +CONFIG_PARAVIRT enabled.
> > > +
> > > +By default this value is 2. Possible values to set are in range {2..16}.
> > > +
> > > +==============================================================
> > > +
> > > +paravirt_poll_shrink: (X86 only)
> > > +
> > > +Divided value to reduce the poll time. This is expected to take effect
> > > +only when running as a virtual machine with CONFIG_PARAVIRT enabled.
> > > +This can't bring any benifit on bare mental even with CONFIG_PARAVIRT
> > > +enabled.
> > > +
> > > +By default this value is 2. Possible values to set are in range {2..16}.
> > > +
> > > +==============================================================
> > > +
> > > +paravirt_poll_threshold_ns: (X86 only)
> > > +
> > > +Controls the maximum poll time before entering real idle path. This is
> > > +expected to take effect only when running as a virtual machine with
> > > +CONFIG_PARAVIRT enabled. This can't bring any benifit on bare mental
> > > +even with CONFIG_PARAVIRT enabled.
> > > +
> > > +By default, this value is 0 means not to poll. Possible values to set
> > > +are in range {0..500000}. Change the value to non-zero if running
> > > +latency-bound workloads in a virtual machine.
> > I absolutely hate it how this hybrid idle loop polling mechanism is not
> > self-tuning!
>
> Ingo, actually it is self-tuning..
Then why the hell does it touch the syscall ABI?
> could I only leave paravirt_poll_threshold_ns parameter (the maximum poll time),
> which is as similar as "adaptive halt-polling" Wanpeng mentioned.. then user can
> turn it off, or find an appropriate threshold for some odd scenario..
That way lies utter madness. Maybe add it as a debugfs knob, but exposing it to
userspace: NAK.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Juergen Gross @ 2017-11-14 7:30 UTC (permalink / raw)
To: Quan Xu, Quan Xu, kvm, linux-doc, linux-fsdevel, linux-kernel,
virtualization, x86, xen-devel
Cc: Yang Zhang, Rusty Russell, Ingo Molnar, H. Peter Anvin,
Alok Kataria, Thomas Gleixner
In-Reply-To: <902da704-1e4f-583b-91c3-1a62ccd6e73d@gmail.com>
On 14/11/17 08:02, Quan Xu wrote:
>
>
> On 2017/11/13 18:53, Juergen Gross wrote:
>> On 13/11/17 11:06, Quan Xu wrote:
>>> From: Quan Xu <quan.xu0@gmail.com>
>>>
>>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
>>> in idle path which will poll for a while before we enter the real idle
>>> state.
>>>
>>> In virtualization, idle path includes several heavy operations
>>> includes timer access(LAPIC timer or TSC deadline timer) which will
>>> hurt performance especially for latency intensive workload like message
>>> passing task. The cost is mainly from the vmexit which is a hardware
>>> context switch between virtual machine and hypervisor. Our solution is
>>> to poll for a while and do not enter real idle path if we can get the
>>> schedule event during polling.
>>>
>>> Poll may cause the CPU waste so we adopt a smart polling mechanism to
>>> reduce the useless poll.
>>>
>>> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
>>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: Alok Kataria <akataria@vmware.com>
>>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: x86@kernel.org
>>> Cc: virtualization@lists.linux-foundation.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>> Hmm, is the idle entry path really so critical to performance that a new
>> pvops function is necessary?
> Juergen, Here is the data we get when running benchmark netperf:
> 1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
> 29031.6 bit/s -- 76.1 %CPU
>
> 2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
> 35787.7 bit/s -- 129.4 %CPU
>
> 3. w/ kvm dynamic poll:
> 35735.6 bit/s -- 200.0 %CPU
>
> 4. w/patch and w/ kvm dynamic poll:
> 42225.3 bit/s -- 198.7 %CPU
>
> 5. idle=poll
> 37081.7 bit/s -- 998.1 %CPU
>
>
>
> w/ this patch, we will improve performance by 23%.. even we could improve
> performance by 45.4%, if we use w/patch and w/ kvm dynamic poll. also the
> cost of CPU is much lower than 'idle=poll' case..
I don't question the general idea. I just think pvops isn't the best way
to implement it.
>> Wouldn't a function pointer, maybe guarded
>> by a static key, be enough? A further advantage would be that this would
>> work on other architectures, too.
>
> I assume this feature will be ported to other archs.. a new pvops makes
> code
> clean and easy to maintain. also I tried to add it into existed pvops,
> but it
> doesn't match.
You are aware that pvops is x86 only?
I really don't see the big difference in maintainability compared to the
static key / function pointer variant:
void (*guest_idle_poll_func)(void);
struct static_key guest_idle_poll_key __read_mostly;
static inline void guest_idle_poll(void)
{
if (static_key_false(&guest_idle_poll_key))
guest_idle_poll_func();
}
And KVM would just need to set guest_idle_poll_func and enable the
static key. Works on non-x86 architectures, too.
Juergen
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Wanpeng Li @ 2017-11-14 7:12 UTC (permalink / raw)
To: Quan Xu
Cc: Juergen Gross, Yang Zhang, Rusty Russell, kvm, linux-doc,
the arch/x86 maintainers, linux-kernel@vger.kernel.org,
virtualization, Ingo Molnar, Quan Xu, H. Peter Anvin,
open list:FILESYSTEMS (VFS and infrastructure), xen-devel,
Alok Kataria, Thomas Gleixner
In-Reply-To: <902da704-1e4f-583b-91c3-1a62ccd6e73d@gmail.com>
2017-11-14 15:02 GMT+08:00 Quan Xu <quan.xu0@gmail.com>:
>
>
> On 2017/11/13 18:53, Juergen Gross wrote:
>>
>> On 13/11/17 11:06, Quan Xu wrote:
>>>
>>> From: Quan Xu <quan.xu0@gmail.com>
>>>
>>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
>>> in idle path which will poll for a while before we enter the real idle
>>> state.
>>>
>>> In virtualization, idle path includes several heavy operations
>>> includes timer access(LAPIC timer or TSC deadline timer) which will
>>> hurt performance especially for latency intensive workload like message
>>> passing task. The cost is mainly from the vmexit which is a hardware
>>> context switch between virtual machine and hypervisor. Our solution is
>>> to poll for a while and do not enter real idle path if we can get the
>>> schedule event during polling.
>>>
>>> Poll may cause the CPU waste so we adopt a smart polling mechanism to
>>> reduce the useless poll.
>>>
>>> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
>>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: Alok Kataria <akataria@vmware.com>
>>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: x86@kernel.org
>>> Cc: virtualization@lists.linux-foundation.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>>
>> Hmm, is the idle entry path really so critical to performance that a new
>> pvops function is necessary?
>
> Juergen, Here is the data we get when running benchmark netperf:
> 1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
> 29031.6 bit/s -- 76.1 %CPU
>
> 2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
> 35787.7 bit/s -- 129.4 %CPU
>
> 3. w/ kvm dynamic poll:
> 35735.6 bit/s -- 200.0 %CPU
Actually we can reduce the CPU utilization by sleeping a period of
time as what has already been done in the poll logic of IO subsystem,
then we can improve the algorithm in kvm instead of introduing another
duplicate one in the kvm guest.
Regards,
Wanpeng Li
>
> 4. w/patch and w/ kvm dynamic poll:
> 42225.3 bit/s -- 198.7 %CPU
>
> 5. idle=poll
> 37081.7 bit/s -- 998.1 %CPU
>
>
>
> w/ this patch, we will improve performance by 23%.. even we could improve
> performance by 45.4%, if we use w/patch and w/ kvm dynamic poll. also the
> cost of CPU is much lower than 'idle=poll' case..
>
>> Wouldn't a function pointer, maybe guarded
>> by a static key, be enough? A further advantage would be that this would
>> work on other architectures, too.
>
>
> I assume this feature will be ported to other archs.. a new pvops makes code
> clean and easy to maintain. also I tried to add it into existed pvops, but
> it
> doesn't match.
>
>
>
> Quan
> Alibaba Cloud
>>
>>
>> Juergen
>>
>
^ permalink raw reply
* Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Quan Xu @ 2017-11-14 7:02 UTC (permalink / raw)
To: Juergen Gross, Quan Xu, kvm, linux-doc, linux-fsdevel,
linux-kernel, virtualization, x86, xen-devel
Cc: Yang Zhang, Rusty Russell, Ingo Molnar, H. Peter Anvin,
Alok Kataria, Thomas Gleixner
In-Reply-To: <07fac696-e3d4-8f35-8f3d-764d7ab41204@suse.com>
On 2017/11/13 18:53, Juergen Gross wrote:
> On 13/11/17 11:06, Quan Xu wrote:
>> From: Quan Xu <quan.xu0@gmail.com>
>>
>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
>> in idle path which will poll for a while before we enter the real idle
>> state.
>>
>> In virtualization, idle path includes several heavy operations
>> includes timer access(LAPIC timer or TSC deadline timer) which will
>> hurt performance especially for latency intensive workload like message
>> passing task. The cost is mainly from the vmexit which is a hardware
>> context switch between virtual machine and hypervisor. Our solution is
>> to poll for a while and do not enter real idle path if we can get the
>> schedule event during polling.
>>
>> Poll may cause the CPU waste so we adopt a smart polling mechanism to
>> reduce the useless poll.
>>
>> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: Alok Kataria <akataria@vmware.com>
>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: virtualization@lists.linux-foundation.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: xen-devel@lists.xenproject.org
> Hmm, is the idle entry path really so critical to performance that a new
> pvops function is necessary?
Juergen, Here is the data we get when running benchmark netperf:
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
29031.6 bit/s -- 76.1 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
35787.7 bit/s -- 129.4 %CPU
3. w/ kvm dynamic poll:
35735.6 bit/s -- 200.0 %CPU
4. w/patch and w/ kvm dynamic poll:
42225.3 bit/s -- 198.7 %CPU
5. idle=poll
37081.7 bit/s -- 998.1 %CPU
w/ this patch, we will improve performance by 23%.. even we could improve
performance by 45.4%, if we use w/patch and w/ kvm dynamic poll. also the
cost of CPU is much lower than 'idle=poll' case..
> Wouldn't a function pointer, maybe guarded
> by a static key, be enough? A further advantage would be that this would
> work on other architectures, too.
I assume this feature will be ported to other archs.. a new pvops makes code
clean and easy to maintain. also I tried to add it into existed pvops,
but it
doesn't match.
Quan
Alibaba Cloud
>
> Juergen
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll
From: Quan Xu @ 2017-11-14 4:05 UTC (permalink / raw)
To: Ingo Molnar, Quan Xu
Cc: Yang Zhang, kvm, linux-doc, x86, linux-kernel, virtualization,
linux-fsdevel
In-Reply-To: <20171113150842.epdffyxhlu5nq37u@gmail.com>
On 2017/11/13 23:08, Ingo Molnar wrote:
> * Quan Xu <quan.xu04@gmail.com> wrote:
>
>> From: Quan Xu <quan.xu0@gmail.com>
>>
>> To reduce the cost of poll, we introduce three sysctl to control the
>> poll time when running as a virtual machine with paravirt.
>>
>> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>> ---
>> Documentation/sysctl/kernel.txt | 35 +++++++++++++++++++++++++++++++++++
>> arch/x86/kernel/paravirt.c | 4 ++++
>> include/linux/kernel.h | 6 ++++++
>> kernel/sysctl.c | 34 ++++++++++++++++++++++++++++++++++
>> 4 files changed, 79 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
>> index 694968c..30c25fb 100644
>> --- a/Documentation/sysctl/kernel.txt
>> +++ b/Documentation/sysctl/kernel.txt
>> @@ -714,6 +714,41 @@ kernel tries to allocate a number starting from this one.
>>
>> ==============================================================
>>
>> +paravirt_poll_grow: (X86 only)
>> +
>> +Multiplied value to increase the poll time. This is expected to take
>> +effect only when running as a virtual machine with CONFIG_PARAVIRT
>> +enabled. This can't bring any benifit on bare mental even with
>> +CONFIG_PARAVIRT enabled.
>> +
>> +By default this value is 2. Possible values to set are in range {2..16}.
>> +
>> +==============================================================
>> +
>> +paravirt_poll_shrink: (X86 only)
>> +
>> +Divided value to reduce the poll time. This is expected to take effect
>> +only when running as a virtual machine with CONFIG_PARAVIRT enabled.
>> +This can't bring any benifit on bare mental even with CONFIG_PARAVIRT
>> +enabled.
>> +
>> +By default this value is 2. Possible values to set are in range {2..16}.
>> +
>> +==============================================================
>> +
>> +paravirt_poll_threshold_ns: (X86 only)
>> +
>> +Controls the maximum poll time before entering real idle path. This is
>> +expected to take effect only when running as a virtual machine with
>> +CONFIG_PARAVIRT enabled. This can't bring any benifit on bare mental
>> +even with CONFIG_PARAVIRT enabled.
>> +
>> +By default, this value is 0 means not to poll. Possible values to set
>> +are in range {0..500000}. Change the value to non-zero if running
>> +latency-bound workloads in a virtual machine.
> I absolutely hate it how this hybrid idle loop polling mechanism is not
> self-tuning!
Ingo, actually it is self-tuning..
> Please make it all work fine by default, and automatically so, instead of adding
> three random parameters...
.. I will make it all fine by default. howerver cloud environment is of
diversity,
could I only leave paravirt_poll_threshold_ns parameter (the maximum
poll time),
which is as similar as "adaptive halt-polling" Wanpeng mentioned.. then
user can turn
it off, or find an appropriate threshold for some odd scenario..
thanks for your comments!!
Quan
Alibaba Cloud
> And if it cannot be done automatically then we should rather not do it at all.
> Maybe the next submitter of a similar feature can think of a better approach.
>
> Thanks,
>
> Ingo
>
^ permalink raw reply
* Re: [PATCH] drm/virtio: add create_handle support.
From: lepton @ 2017-11-13 22:19 UTC (permalink / raw)
To: airlied, kraxel; +Cc: Lepton Wu, dri-devel, virtualization
In-Reply-To: <20171108184209.46211-1-ytht.net@gmail.com>
Ping.
On Wed, Nov 8, 2017 at 10:42 AM, Lepton Wu <ytht.net@gmail.com> wrote:
> Add create_handle support to virtio fb. Without this, screenshot tool
> in chromium OS can't work.
>
> Signed-off-by: Lepton Wu <ytht.net@gmail.com>
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
> index b6d52055a11f..274b4206ca96 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -71,7 +71,19 @@ virtio_gpu_framebuffer_surface_dirty(struct drm_framebuffer *fb,
> return virtio_gpu_surface_dirty(virtio_gpu_fb, clips, num_clips);
> }
>
> +static int
> +virtio_gpu_framebuffer_create_handle(struct drm_framebuffer *fb,
> + struct drm_file *file_priv,
> + unsigned int *handle)
> +{
> + struct virtio_gpu_framebuffer *virtio_gpu_fb =
> + to_virtio_gpu_framebuffer(fb);
> +
> + return drm_gem_handle_create(file_priv, virtio_gpu_fb->obj, handle);
> +}
> +
> static const struct drm_framebuffer_funcs virtio_gpu_fb_funcs = {
> + .create_handle = virtio_gpu_framebuffer_create_handle,
> .destroy = virtio_gpu_user_framebuffer_destroy,
> .dirty = virtio_gpu_framebuffer_surface_dirty,
> };
> --
> 2.15.0.403.gc27cc4dac6-goog
>
^ permalink raw reply
* [CISTI 2018]: Call for Workshops Proposals
From: ML @ 2017-11-13 22:05 UTC (permalink / raw)
To: virtualization
[-- Attachment #1: Type: text/plain, Size: 5214 bytes --]
------------------------------------------------------------------
CISTI'2018 WORKSHOPS
13th Iberian Conference on Information Systems and Technologies
13 - 16 June 2018, Caceres, Spain
http://www.cisti.eu/
---------------------------------------------------------------------------
WORKSHOPS FORMAT
The Iberian Information Systems and Technologies research and industrial community is invited to submit proposals of Workshops for CISTI 2018 – 13th Iberian Conference on Information Systems and Technologies to be held at Cáceres, Spain, June 13–16, 2018. Two types of Workshops may be proposed: Regular Workshops and Project Workshops.
Regular Workshops should focus on a specific scientific subject on the scope of CISTI 2018 but not directly included on the main conference areas. Each regular workshop will be coordinated by an Organizing Committee composed of, at least, two researchers in the field, preferably from different institutions and different countries. The organizers should create an international Program Committee for the Workshop, with recognized researchers within the specific Workshop scientific area. Each workshop should have at least 10 submissions and 5 accepted papers in order to be conducted at CISTI.
Project Workshops are intended to promote the dissemination and facilitate the future exploitation of EU Latin-American and national project results such as EU/FP7, EU/Horizon2020, CSIC, FCT, QREN, Portugal 2020, Fund. Gulbenkian, CYTED, CAPES, CNPq, FINEP and other Projects/funding sources. The results to be disseminated may be preliminary project results (for unfinished projects) or the project final results (for already finished projects). Each project workshop should be directly related to a Project funded in a competitive manner by a National/International Science Organization. The Workshop should be coordinated by an Organizing Committee composed by at least two researchers including the Principal Investigator of the project. Each project Workshop will be entitled to at least a paper on the Conference main proceedings (specific details and distinct configurations for the project workshop should be discussed with the conference Workshop chair).
The selection of Workshops will be performed by CISTI 2018 Conference Chairs. Workshops full papers will be published in the conference main proceedings in specific Workshop chapters. Proceedings will be submitted for indexation by ISI Thomson, SCOPUS, EI-Conpendex, INSPEC and Google Scholar. Detailed and up-to-date information may be found at CISTI 2018 website: http://www.cisti.eu/.
WORKSHOPS ORGANIZATION
The Organizing Committee of each Workshop will be responsible for:
· Producing and distributing the Workshop Call for Papers (CFP);
· Coordinating the review and selection process for the papers submitted to the Workshop, as Workshop chairs (on the paper submission system installed for all the Workshops);
· Delivering the final versions of the papers accepted for the Workshop in accordance with the guidelines and deadlines defined by CISTI 2018 organizers;
· Coordinating and chairing the Workshop sessions at the conference.
CISTI 2018 organizers reserve the right to cancel any Workshop if deadlines are missed or if the number of registered attendees is too low to support the costs associated with the Workshop.
PROPOSAL CONTENTS
Regular Workshop proposals should contain the following information:
· Workshop title;
· Brief description of the specific scientific scope of the Workshop;
· List of topics of interest (max 15 topics);
· Reasons the Workshop should be held within CISTI’2018;
· Name, postal address, phone and email of all the members of the Workshop Organizing Committee;
· Proposal for the Workshop Program Committee (Names and affiliations).
Project Workshop proposals should contain the following information:
· Workshop title;
· Project Title, Reference, Principal Investigator, Funding Organization, Total Funding, Consortium, Abstract and Objectives;
· Reasons the Workshop should be held within CISTI’2018;
· Name, postal address, phone and email of all the members of the Workshop Organizing Committee.
Proposals should be submitted electronically (in Word or compatible format) at https://easychair.org/conferences/?conf=cisti2018workshops, in English, Portuguese and/or Spanish, by November 26, 2017.
IMPORTANT DATES
· Deadline for Workshop proposals: November 26, 2017
· Notification of Workshop acceptance: November 30, 2017
· Deadline for paper submission: February 18, 2018
· Notification of paper acceptance: March 26, 2018
· Deadline for final versions and conference registration: April 1, 2018
· Deadline for Workshop final papers delivery to CISTI organizers: April 8, 2018
· Conference dates: June 13-16, 2018
Kind regards,
CISTI'2018 Team
http://www.cisti.eu/
-----------------------
---
This email has been checked for viruses by AVG.
http://www.avg.com
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll
From: Wanpeng Li @ 2017-11-13 21:44 UTC (permalink / raw)
To: Ingo Molnar, Quan Xu
Cc: Yang Zhang, Quan Xu, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Andi Kleen,
linux-fsdevel@vger.kernel.org
In-Reply-To: <20171113150842.epdffyxhlu5nq37u@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3108 bytes --]
Hi Ingo,
On 11/13/17 11:08 PM, Ingo Molnar wrote:
* Quan Xu <quan.xu04@gmail.com><mailto:quan.xu04@gmail.com> wrote:
From: Quan Xu <quan.xu0@gmail.com><mailto:quan.xu0@gmail.com>
To reduce the cost of poll, we introduce three sysctl to control the
poll time when running as a virtual machine with paravirt.
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com><mailto:yang.zhang.wz@gmail.com>
Signed-off-by: Quan Xu <quan.xu0@gmail.com><mailto:quan.xu0@gmail.com>
---
Documentation/sysctl/kernel.txt | 35 +++++++++++++++++++++++++++++++++++
arch/x86/kernel/paravirt.c | 4 ++++
include/linux/kernel.h | 6 ++++++
kernel/sysctl.c | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 694968c..30c25fb 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -714,6 +714,41 @@ kernel tries to allocate a number starting from this one.
==============================================================
+paravirt_poll_grow: (X86 only)
+
+Multiplied value to increase the poll time. This is expected to take
+effect only when running as a virtual machine with CONFIG_PARAVIRT
+enabled. This can't bring any benifit on bare mental even with
+CONFIG_PARAVIRT enabled.
+
+By default this value is 2. Possible values to set are in range {2..16}.
+
+==============================================================
+
+paravirt_poll_shrink: (X86 only)
+
+Divided value to reduce the poll time. This is expected to take effect
+only when running as a virtual machine with CONFIG_PARAVIRT enabled.
+This can't bring any benifit on bare mental even with CONFIG_PARAVIRT
+enabled.
+
+By default this value is 2. Possible values to set are in range {2..16}.
+
+==============================================================
+
+paravirt_poll_threshold_ns: (X86 only)
+
+Controls the maximum poll time before entering real idle path. This is
+expected to take effect only when running as a virtual machine with
+CONFIG_PARAVIRT enabled. This can't bring any benifit on bare mental
+even with CONFIG_PARAVIRT enabled.
+
+By default, this value is 0 means not to poll. Possible values to set
+are in range {0..500000}. Change the value to non-zero if running
+latency-bound workloads in a virtual machine.
I absolutely hate it how this hybrid idle loop polling mechanism is not
self-tuning!
Please make it all work fine by default, and automatically so, instead of adding
three random parameters...
And if it cannot be done automatically then we should rather not do it at all.
One of the main benefit of this patchset is the customers who use the VM can tune the mechanism by themself. I remember Andi also has the concern about two much random parameters. In addition, there is a "Adaptive halt-polling" which are merged to upstream more than two years ago in kvm which is self-tuning, https://lkml.org/lkml/2015/9/3/615
Regards,
Wanpeng Li
[-- Attachment #1.2: Type: text/html, Size: 4520 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
From: Michael S. Tsirkin @ 2017-11-13 17:32 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, kvm, penguin-kernel, liliang.opensource,
qemu-devel, virtualization, linux-mm, aarcange, virtio-dev,
mawilcox, willy, quan.xu, Nitesh Narayan Lal, Rik van Riel,
cornelia.huck, mhocko, linux-kernel, amit.shah, pbonzini, akpm,
mgorman
In-Reply-To: <5A097548.8000608@intel.com>
You should Cc Nitesh who is working on a related feature.
On Mon, Nov 13, 2017 at 06:34:48PM +0800, Wei Wang wrote:
> Ping for comments, thanks.
>
> On 11/03/2017 04:13 PM, Wei Wang wrote:
> > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
> > support of reporting hints of guest free pages to the host via
> > virtio-balloon. The host requests the guest to report the free pages by
> > sending commands via the virtio-balloon configuration registers.
> >
> > When the guest starts to report, the first element added to the free page
> > vq is a sequence id of the start reporting command. The id is given by
> > the host, and it indicates whether the following free pages correspond
> > to the command. For example, the host may stop the report and start again
> > with a new command id. The obsolete pages for the previous start command
> > can be detected by the id dismatching on the host. The id is added to the
> > vq using an output buffer, and the free pages are added to the vq using
> > input buffer.
> >
> > Here are some explainations about the added configuration registers:
> > - host2guest_cmd: a register used by the host to send commands to the
> > guest.
> > - guest2host_cmd: written by the guest to ACK to the host about the
> > commands that have been received. The host will clear the corresponding
> > bits on the host2guest_cmd register. The guest also uses this register
> > to send commands to the host (e.g. when finish free page reporting).
I am not sure what is the role of guest2host_cmd. Reporting of
the correct cmd id seems sufficient indication that guest
received the start command. Not getting any more seems sufficient
to detect stop.
> > - free_page_cmd_id: the sequence id of the free page report command
> > given by the host.
> >
> > Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> > Signed-off-by: Liang Li <liang.z.li@intel.com>
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: Michal Hocko <mhocko@kernel.org>
> > ---
> > drivers/virtio/virtio_balloon.c | 234 ++++++++++++++++++++++++++++++++----
> > include/uapi/linux/virtio_balloon.h | 11 ++
> > 2 files changed, 223 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > index b31fc25..4087f04 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -55,7 +55,12 @@ static struct vfsmount *balloon_mnt;
> > struct virtio_balloon {
> > struct virtio_device *vdev;
> > - struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> > + struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
> > +
> > + /* Balloon's own wq for cpu-intensive work items */
> > + struct workqueue_struct *balloon_wq;
> > + /* The free page reporting work item submitted to the balloon wq */
> > + struct work_struct report_free_page_work;
> > /* The balloon servicing is delegated to a freezable workqueue. */
> > struct work_struct update_balloon_stats_work;
> > @@ -65,6 +70,10 @@ struct virtio_balloon {
> > spinlock_t stop_update_lock;
> > bool stop_update;
> > + /* Stop reporting free pages */
> > + bool report_free_page_stop;
I would revert logic here: bool report_free_page;
> > + uint32_t free_page_cmd_id;
> > +
> > /* Waiting for host to ack the pages we released. */
> > wait_queue_head_t acked;
> > @@ -191,6 +200,30 @@ static void send_balloon_page_sg(struct virtio_balloon *vb,
> > kick_and_wait(vq, vb->acked);
> > }
> > +static void send_free_page_sg(struct virtqueue *vq, void *addr, uint32_t size)
> > +{
> > + int err = 0;
> > + unsigned int len;
> > +
> > + /* Detach all the used buffers from the vq */
> > + while (virtqueue_get_buf(vq, &len))
> > + ;
> > +
> > + /*
> > + * Since this is an optimization feature, losing a couple of free
> > + * pages to report isn't important. We simply resturn without adding
> > + * the page if the vq is full.
> > + */
> > + if (vq->num_free) {
> > + err = add_one_sg(vq, addr, size);
> > + BUG_ON(err);
> > + }
> > +
> > + /* Batch till the vq is full */
> > + if (!vq->num_free)
> > + virtqueue_kick(vq);
> > +}
> > +
> > /*
> > * Send balloon pages in sgs to host. The balloon pages are recorded in the
> > * page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
> > @@ -495,9 +528,8 @@ static void stats_handle_request(struct virtio_balloon *vb)
> > virtqueue_kick(vq);
> > }
> > -static void virtballoon_changed(struct virtio_device *vdev)
> > +static void virtballoon_cmd_balloon_memory(struct virtio_balloon *vb)
> > {
> > - struct virtio_balloon *vb = vdev->priv;
> > unsigned long flags;
> > spin_lock_irqsave(&vb->stop_update_lock, flags);
> > @@ -506,6 +538,50 @@ static void virtballoon_changed(struct virtio_device *vdev)
> > spin_unlock_irqrestore(&vb->stop_update_lock, flags);
> > }
> > +static void virtballoon_cmd_report_free_page_start(struct virtio_balloon *vb)
> > +{
> > + unsigned long flags;
> > +
> > + vb->report_free_page_stop = false;
this flag is used a lot outside any locks. Why is this safe?
Please add some comments explaining access to this flag.
> > + spin_lock_irqsave(&vb->stop_update_lock, flags);
> > + if (!vb->stop_update)
> > + queue_work(vb->balloon_wq, &vb->report_free_page_work);
> > + spin_unlock_irqrestore(&vb->stop_update_lock, flags);
> > +}
> > +
> > +static void virtballoon_changed(struct virtio_device *vdev)
> > +{
> > + struct virtio_balloon *vb = vdev->priv;
> > + u32 host2guest_cmd, guest2host_cmd = 0;
> > +
> > + if (!virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ)) {
> > + virtballoon_cmd_balloon_memory(vb);
> > + return;
This might be a handy feature: one can disable balloon without
hot-unplug. But I would use a separate feature flag to
control it.
> > + }
> > +
> > + virtio_cread(vb->vdev, struct virtio_balloon_config, host2guest_cmd,
> > + &host2guest_cmd);
> > +
> > + if (host2guest_cmd & VIRTIO_BALLOON_CMD_BALLOON_MEMORY) {
> > + virtballoon_cmd_balloon_memory(vb);
> > + guest2host_cmd |= VIRTIO_BALLOON_CMD_BALLOON_MEMORY;
> > + }
> > +
> > + if (host2guest_cmd & VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_START) {
> > + virtballoon_cmd_report_free_page_start(vb);
> > + guest2host_cmd |= VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_START;
> > + }
> > +
> > + if (host2guest_cmd & VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP) {
> > + vb->report_free_page_stop = true;
> > + guest2host_cmd |= VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP;
> > + }
I am not sure why free page has start+stop but e.g. balloon has a single
bit. In fact I would really just use command id. When it changes, we
know a new report is needed.
> > +
> > + /* Ack to the host about the commands that have been received */
> > + virtio_cwrite(vb->vdev, struct virtio_balloon_config, guest2host_cmd,
> > + &guest2host_cmd);
So the same register is used to ack stop command and to signal
end of report. This seems buggy.
> > +}
> > +
> > static inline s64 towards_target(struct virtio_balloon *vb)
> > {
> > s64 target;
> > @@ -597,42 +673,147 @@ static void update_balloon_size_func(struct work_struct *work)
> > queue_work(system_freezable_wq, work);
> > }
> > -static int init_vqs(struct virtio_balloon *vb)
> > +static bool virtio_balloon_send_free_pages(void *opaque, unsigned long pfn,
> > + unsigned long nr_pages)
> > {
> > - struct virtqueue *vqs[3];
> > - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request };
> > - static const char * const names[] = { "inflate", "deflate", "stats" };
> > - int err, nvqs;
> > + struct virtio_balloon *vb = (struct virtio_balloon *)opaque;
> > + void *addr = (void *)pfn_to_kaddr(pfn);
How do we know all free pages have a kaddr?
> > + uint32_t len = nr_pages << PAGE_SHIFT;
> > +
> > + if (vb->report_free_page_stop)
> > + return false;
> > +
> > + send_free_page_sg(vb->free_page_vq, addr, len);
> > + return true;
> > +}
> > +
> > +static void report_free_page_end(struct virtio_balloon *vb)
> > +{
> > + u32 cmd = VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP;
> > /*
> > - * We expect two virtqueues: inflate and deflate, and
> > - * optionally stat.
> > + * The host may have already requested to stop the reporting before we
> > + * finish, so no need to notify the host in this case.
> > */
> > - nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2;
> > - err = virtio_find_vqs(vb->vdev, nvqs, vqs, callbacks, names, NULL);
> > + if (vb->report_free_page_stop)
> > + return;
> > + vb->report_free_page_stop = true;
> > +
> > + virtio_cwrite(vb->vdev, struct virtio_balloon_config, guest2host_cmd,
> > + &cmd);
Wouldn't it be easier to add a buffer in the queue?
> > +}
> > +
> > +static void report_free_page_cmd_id(struct virtio_balloon *vb)
> > +{
> > + struct scatterlist sg;
> > + int err;
> > +
> > + virtio_cread(vb->vdev, struct virtio_balloon_config, free_page_cmd_id,
> > + &vb->free_page_cmd_id);
> > + sg_init_one(&sg, &vb->free_page_cmd_id, sizeof(uint32_t));
> > + err = virtqueue_add_outbuf(vb->free_page_vq, &sg, 1,
> > + &vb->free_page_cmd_id, GFP_KERNEL);
> > + BUG_ON(err);
> > +}
> > +
> > +static void report_free_page(struct work_struct *work)
> > +{
> > + struct virtio_balloon *vb;
> > +
> > + vb = container_of(work, struct virtio_balloon, report_free_page_work);
> > + report_free_page_cmd_id(vb);
> > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
> > + /*
> > + * The last few free page blocks that were added may not reach the
> > + * batch size, but need a kick to notify the device to handle them.
> > + */
> > + virtqueue_kick(vb->free_page_vq);
> > + report_free_page_end(vb);
> > +}
> > +
> > +static int init_vqs(struct virtio_balloon *vb)
> > +{
> > + struct virtqueue **vqs;
> > + vq_callback_t **callbacks;
> > + const char **names;
> > + struct scatterlist sg;
> > + int i, nvqs, err = -ENOMEM;
> > +
> > + /* Inflateq and deflateq are used unconditionally */
> > + nvqs = 2;
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
> > + nvqs++;
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ))
> > + nvqs++;
> > +
> > + /* Allocate space for find_vqs parameters */
> > + vqs = kcalloc(nvqs, sizeof(*vqs), GFP_KERNEL);
> > + if (!vqs)
> > + goto err_vq;
> > + callbacks = kmalloc_array(nvqs, sizeof(*callbacks), GFP_KERNEL);
> > + if (!callbacks)
> > + goto err_callback;
> > + names = kmalloc_array(nvqs, sizeof(*names), GFP_KERNEL);
> > + if (!names)
> > + goto err_names;
> > +
> > + callbacks[0] = balloon_ack;
> > + names[0] = "inflate";
> > + callbacks[1] = balloon_ack;
> > + names[1] = "deflate";
> > +
> > + i = 2;
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > + callbacks[i] = stats_request;
> > + names[i] = "stats";
> > + i++;
> > + }
> > +
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ)) {
> > + callbacks[i] = NULL;
> > + names[i] = "free_page_vq";
> > + }
> > +
> > + err = vb->vdev->config->find_vqs(vb->vdev, nvqs, vqs, callbacks, names,
> > + NULL, NULL);
> > if (err)
> > - return err;
> > + goto err_find;
> > vb->inflate_vq = vqs[0];
> > vb->deflate_vq = vqs[1];
> > + i = 2;
> > if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > - struct scatterlist sg;
> > - unsigned int num_stats;
> > - vb->stats_vq = vqs[2];
> > -
> > + vb->stats_vq = vqs[i++];
> > /*
> > * Prime this virtqueue with one buffer so the hypervisor can
> > * use it to signal us later (it can't be broken yet!).
> > */
> > - num_stats = update_balloon_stats(vb);
> > -
> > - sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
> > + sg_init_one(&sg, vb->stats, sizeof(vb->stats));
> > if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)
> > - < 0)
> > - BUG();
> > + < 0) {
> > + dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n",
> > + __func__);
> > + goto err_find;
> > + }
> > virtqueue_kick(vb->stats_vq);
> > }
> > +
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ))
> > + vb->free_page_vq = vqs[i];
> > +
> > + kfree(names);
> > + kfree(callbacks);
> > + kfree(vqs);
> > return 0;
> > +
> > +err_find:
> > + kfree(names);
> > +err_names:
> > + kfree(callbacks);
> > +err_callback:
> > + kfree(vqs);
> > +err_vq:
> > + return err;
> > }
> > #ifdef CONFIG_BALLOON_COMPACTION
> > @@ -761,6 +942,13 @@ static int virtballoon_probe(struct virtio_device *vdev)
> > if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_SG))
> > xb_init(&vb->page_xb);
> > + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ)) {
> > + vb->balloon_wq = alloc_workqueue("balloon-wq",
> > + WQ_FREEZABLE | WQ_CPU_INTENSIVE, 0);
> > + INIT_WORK(&vb->report_free_page_work, report_free_page);
> > + vb->report_free_page_stop = true;
> > + }
> > +
> > vb->nb.notifier_call = virtballoon_oom_notify;
> > vb->nb.priority = VIRTBALLOON_OOM_NOTIFY_PRIORITY;
> > err = register_oom_notifier(&vb->nb);
> > @@ -825,6 +1013,7 @@ static void virtballoon_remove(struct virtio_device *vdev)
> > spin_unlock_irq(&vb->stop_update_lock);
> > cancel_work_sync(&vb->update_balloon_size_work);
> > cancel_work_sync(&vb->update_balloon_stats_work);
> > + cancel_work_sync(&vb->report_free_page_work);
> > remove_common(vb);
> > #ifdef CONFIG_BALLOON_COMPACTION
> > @@ -878,6 +1067,7 @@ static unsigned int features[] = {
> > VIRTIO_BALLOON_F_STATS_VQ,
> > VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> > VIRTIO_BALLOON_F_SG,
> > + VIRTIO_BALLOON_F_FREE_PAGE_VQ,
> > };
> > static struct virtio_driver virtio_balloon_driver = {
> > diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> > index 37780a7..b758484 100644
> > --- a/include/uapi/linux/virtio_balloon.h
> > +++ b/include/uapi/linux/virtio_balloon.h
> > @@ -35,15 +35,26 @@
> > #define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
> > #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */
> > #define VIRTIO_BALLOON_F_SG 3 /* Use sg instead of PFN lists */
> > +#define VIRTIO_BALLOON_F_FREE_PAGE_VQ 4 /* VQ to report free pages */
> > /* Size of a PFN in the balloon interface. */
> > #define VIRTIO_BALLOON_PFN_SHIFT 12
> > +#define VIRTIO_BALLOON_CMD_BALLOON_MEMORY (1 << 0)
> > +#define VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_START (1 << 1)
> > +#define VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP (1 << 2)
> > +
> > struct virtio_balloon_config {
> > /* Number of pages host wants Guest to give up. */
> > __u32 num_pages;
> > /* Number of pages we've actually got in balloon. */
> > __u32 actual;
> > + /* Host-to-guest command, readonly by guest */
> > + __u32 host2guest_cmd;
> > + /* Sequence id of the free_page report command, readonly by guest */
> > + __u32 free_page_cmd_id;
> > + /* Guest-to-host command */
> > + __u32 guest2host_cmd;
> > };
> > #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */
^ permalink raw reply
* Re: [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll
From: Ingo Molnar @ 2017-11-13 15:08 UTC (permalink / raw)
To: Quan Xu
Cc: Yang Zhang, Quan Xu, kvm, linux-doc, x86, linux-kernel,
virtualization, linux-fsdevel
In-Reply-To: <1510570064-6178-1-git-send-email-quan.xu0@gmail.com>
* Quan Xu <quan.xu04@gmail.com> wrote:
> From: Quan Xu <quan.xu0@gmail.com>
>
> To reduce the cost of poll, we introduce three sysctl to control the
> poll time when running as a virtual machine with paravirt.
>
> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
> ---
> Documentation/sysctl/kernel.txt | 35 +++++++++++++++++++++++++++++++++++
> arch/x86/kernel/paravirt.c | 4 ++++
> include/linux/kernel.h | 6 ++++++
> kernel/sysctl.c | 34 ++++++++++++++++++++++++++++++++++
> 4 files changed, 79 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 694968c..30c25fb 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -714,6 +714,41 @@ kernel tries to allocate a number starting from this one.
>
> ==============================================================
>
> +paravirt_poll_grow: (X86 only)
> +
> +Multiplied value to increase the poll time. This is expected to take
> +effect only when running as a virtual machine with CONFIG_PARAVIRT
> +enabled. This can't bring any benifit on bare mental even with
> +CONFIG_PARAVIRT enabled.
> +
> +By default this value is 2. Possible values to set are in range {2..16}.
> +
> +==============================================================
> +
> +paravirt_poll_shrink: (X86 only)
> +
> +Divided value to reduce the poll time. This is expected to take effect
> +only when running as a virtual machine with CONFIG_PARAVIRT enabled.
> +This can't bring any benifit on bare mental even with CONFIG_PARAVIRT
> +enabled.
> +
> +By default this value is 2. Possible values to set are in range {2..16}.
> +
> +==============================================================
> +
> +paravirt_poll_threshold_ns: (X86 only)
> +
> +Controls the maximum poll time before entering real idle path. This is
> +expected to take effect only when running as a virtual machine with
> +CONFIG_PARAVIRT enabled. This can't bring any benifit on bare mental
> +even with CONFIG_PARAVIRT enabled.
> +
> +By default, this value is 0 means not to poll. Possible values to set
> +are in range {0..500000}. Change the value to non-zero if running
> +latency-bound workloads in a virtual machine.
I absolutely hate it how this hybrid idle loop polling mechanism is not
self-tuning!
Please make it all work fine by default, and automatically so, instead of adding
three random parameters...
And if it cannot be done automatically then we should rather not do it at all.
Maybe the next submitter of a similar feature can think of a better approach.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add virtio-ccw.h to virtio/s390 section
From: Halil Pasic @ 2017-11-13 13:35 UTC (permalink / raw)
To: Heiko Carstens, Cornelia Huck
Cc: schwidefsky, linux-s390, kvm, virtualization
In-Reply-To: <20171110181558.GB3028@osiris>
On 11/10/2017 07:15 PM, Heiko Carstens wrote:
> On Fri, Nov 10, 2017 at 03:56:11PM +0100, Cornelia Huck wrote:
>> The file arch/s390/include/uapi/asm/virtio-ccw.h belongs to the
>> s390 virtio drivers as well.
>>
>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>> ---
>>
>> Martin, Heiko: It's probably best to take this through your tree.
>>
>> ---
>> MAINTAINERS | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 6671f375f7fc..48c6f1179b9b 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -14312,6 +14312,7 @@ L: virtualization@lists.linux-foundation.org
>> L: kvm@vger.kernel.org
>> S: Supported
>> F: drivers/s390/virtio/
>> +F: arch/s390/include/uapi/asm/virtio-ccw.h
>
> Applied, thanks.
>
^ permalink raw reply
* Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Wanpeng Li @ 2017-11-13 11:09 UTC (permalink / raw)
To: Juergen Gross
Cc: Yang Zhang, Rusty Russell, Quan Xu, kvm, linux-doc,
the arch/x86 maintainers, linux-kernel@vger.kernel.org,
virtualization, Ingo Molnar, Quan Xu, H. Peter Anvin,
open list:FILESYSTEMS (VFS and infrastructure), xen-devel,
Alok Kataria, Thomas Gleixner
In-Reply-To: <07fac696-e3d4-8f35-8f3d-764d7ab41204@suse.com>
2017-11-13 18:53 GMT+08:00 Juergen Gross <jgross@suse.com>:
> On 13/11/17 11:06, Quan Xu wrote:
>> From: Quan Xu <quan.xu0@gmail.com>
>>
>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
>> in idle path which will poll for a while before we enter the real idle
>> state.
>>
>> In virtualization, idle path includes several heavy operations
>> includes timer access(LAPIC timer or TSC deadline timer) which will
>> hurt performance especially for latency intensive workload like message
>> passing task. The cost is mainly from the vmexit which is a hardware
>> context switch between virtual machine and hypervisor. Our solution is
>> to poll for a while and do not enter real idle path if we can get the
>> schedule event during polling.
>>
>> Poll may cause the CPU waste so we adopt a smart polling mechanism to
>> reduce the useless poll.
>>
>> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
>> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: Alok Kataria <akataria@vmware.com>
>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: virtualization@lists.linux-foundation.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: xen-devel@lists.xenproject.org
>
> Hmm, is the idle entry path really so critical to performance that a new
> pvops function is necessary? Wouldn't a function pointer, maybe guarded
> by a static key, be enough? A further advantage would be that this would
> work on other architectures, too.
There is a "Adaptive halt-polling" which are merged to upstream more
than two years ago avoids to thread the critical path and has already
been ported to other architectures. https://lkml.org/lkml/2015/9/3/615
Regards,
Wanpeng Li
^ permalink raw reply
* [PATCH RFC v3 0/6] x86/idle: add halt poll support
From: Quan Xu @ 2017-11-13 11:01 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86
Cc: peterz, pbonzini, tglx, Quan Xu, yang.zhang.wz
From: Quan Xu <quan.xu0@gmail.com>
Some latency-intensive workload have seen obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost I have seen is
inside idle path.
This patch introduces a new mechanism to poll for a while before
entering idle state. If schedule is needed during poll, then we
don't need to goes through the heavy overhead path.
Here is the data we get when running benchmark contextswitch to measure
the latency(lower is better):
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
3402.9 ns/ctxsw -- 199.8 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
halt_poll_threshold=10000 -- 1151.4 ns/ctxsw -- 200.1 %CPU
halt_poll_threshold=20000 -- 1149.7 ns/ctxsw -- 199.9 %CPU
halt_poll_threshold=30000 -- 1151.0 ns/ctxsw -- 199.9 %CPU
halt_poll_threshold=40000 -- 1155.4 ns/ctxsw -- 199.3 %CPU
halt_poll_threshold=50000 -- 1161.0 ns/ctxsw -- 200.0 %CPU
halt_poll_threshold=100000 -- 1163.8 ns/ctxsw -- 200.4 %CPU
halt_poll_threshold=300000 -- 1159.4 ns/ctxsw -- 201.9 %CPU
halt_poll_threshold=500000 -- 1163.5 ns/ctxsw -- 205.5 %CPU
3. w/ kvm dynamic poll:
halt_poll_ns=10000 -- 3470.5 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=20000 -- 3273.0 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=30000 -- 3628.7 ns/ctxsw -- 199.4 %CPU
halt_poll_ns=40000 -- 2280.6 ns/ctxsw -- 199.5 %CPU
halt_poll_ns=50000 -- 3200.3 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=100000 -- 2186.6 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=300000 -- 3178.7 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=500000 -- 3505.4 ns/ctxsw -- 199.7 %CPU
4. w/patch and w/ kvm dynamic poll:
halt_poll_ns=10000 & halt_poll_threshold=10000 -- 1155.5 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=20000 -- 1165.6 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=30000 -- 1161.1 ns/ctxsw -- 200.0 %CPU
halt_poll_ns=20000 & halt_poll_threshold=10000 -- 1158.1 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=20000 & halt_poll_threshold=20000 -- 1161.0 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=20000 & halt_poll_threshold=30000 -- 1163.7 ns/ctxsw -- 199.9 %CPU
halt_poll_ns=30000 & halt_poll_threshold=10000 -- 1158.7 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=30000 & halt_poll_threshold=20000 -- 1153.8 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=30000 & halt_poll_threshold=30000 -- 1155.1 ns/ctxsw -- 199.8 %CPU
5. idle=poll
3957.57 ns/ctxsw -- 999.4%CPU
Here is the data we get when running benchmark netperf:
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
29031.6 bit/s -- 76.1 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
halt_poll_threshold=10000 -- 29021.7 bit/s -- 105.1 %CPU
halt_poll_threshold=20000 -- 33463.5 bit/s -- 128.2 %CPU
halt_poll_threshold=30000 -- 34436.4 bit/s -- 127.8 %CPU
halt_poll_threshold=40000 -- 35563.3 bit/s -- 129.6 %CPU
halt_poll_threshold=50000 -- 35787.7 bit/s -- 129.4 %CPU
halt_poll_threshold=100000 -- 35477.7 bit/s -- 130.0 %CPU
halt_poll_threshold=300000 -- 35730.0 bit/s -- 132.4 %CPU
halt_poll_threshold=500000 -- 34978.4 bit/s -- 134.2 %CPU
3. w/ kvm dynamic poll:
halt_poll_ns=10000 -- 28849.8 bit/s -- 75.2 %CPU
halt_poll_ns=20000 -- 29004.8 bit/s -- 76.1 %CPU
halt_poll_ns=30000 -- 35662.0 bit/s -- 199.7 %CPU
halt_poll_ns=40000 -- 35874.8 bit/s -- 187.5 %CPU
halt_poll_ns=50000 -- 35603.1 bit/s -- 199.8 %CPU
halt_poll_ns=100000 -- 35588.8 bit/s -- 200.0 %CPU
halt_poll_ns=300000 -- 35912.4 bit/s -- 200.0 %CPU
halt_poll_ns=500000 -- 35735.6 bit/s -- 200.0 %CPU
4. w/patch and w/ kvm dynamic poll:
halt_poll_ns=10000 & halt_poll_threshold=10000 -- 29427.9 bit/s -- 107.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=20000 -- 33048.4 bit/s -- 128.1 %CPU
halt_poll_ns=10000 & halt_poll_threshold=30000 -- 35129.8 bit/s -- 129.1 %CPU
halt_poll_ns=20000 & halt_poll_threshold=10000 -- 31091.3 bit/s -- 130.3 %CPU
halt_poll_ns=20000 & halt_poll_threshold=20000 -- 33587.9 bit/s -- 128.9 %CPU
halt_poll_ns=20000 & halt_poll_threshold=30000 -- 35532.9 bit/s -- 129.1 %CPU
halt_poll_ns=30000 & halt_poll_threshold=10000 -- 35633.1 bit/s -- 199.4 %CPU
halt_poll_ns=30000 & halt_poll_threshold=20000 -- 42225.3 bit/s -- 198.7 %CPU
halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU
5. idle=poll
37081.7 bit/s -- 998.1 %CPU
---
V2 -> V3:
- move poll update into arch/. in v3, poll update is based on duration of the
last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit,
and try our best not to interfere with scheduler/idle code. (This seems
not to follow Peter's v2 comment, however we had a f2f discussion about it
in Prague.)
- enhance patch desciption.
- enhance Documentation and sysctls.
- test with IRQ_TIMINGS related code, which seems not working so far.
V1 -> V2:
- integrate the smart halt poll into paravirt code
- use idle_stamp instead of check_poll
- since it hard to get whether vcpu is the only task in pcpu, so we
don't consider it in this series.(May improve it in future)
---
Quan Xu (4):
x86/paravirt: Add pv_idle_ops to paravirt ops
KVM guest: register kvm_idle_poll for pv_idle_ops
Documentation: Add three sysctls for smart idle poll
tick: get duration of the last idle loop
Yang Zhang (2):
sched/idle: Add a generic poll before enter real idle path
KVM guest: introduce smart idle poll algorithm
Documentation/sysctl/kernel.txt | 35 ++++++++++++++++
arch/x86/include/asm/paravirt.h | 5 ++
arch/x86/include/asm/paravirt_types.h | 6 +++
arch/x86/kernel/kvm.c | 73 +++++++++++++++++++++++++++++++++
arch/x86/kernel/paravirt.c | 10 +++++
arch/x86/kernel/process.c | 7 +++
include/linux/kernel.h | 6 +++
include/linux/tick.h | 2 +
kernel/sched/idle.c | 2 +
kernel/sysctl.c | 34 +++++++++++++++
kernel/time/tick-sched.c | 11 +++++
kernel/time/tick-sched.h | 3 +
12 files changed, 194 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Juergen Gross @ 2017-11-13 10:53 UTC (permalink / raw)
To: Quan Xu, kvm, linux-doc, linux-fsdevel, linux-kernel,
virtualization, x86, xen-devel
Cc: Yang Zhang, Quan Xu, Rusty Russell, Ingo Molnar, H. Peter Anvin,
Alok Kataria, Thomas Gleixner
In-Reply-To: <1510567565-5118-2-git-send-email-quan.xu0@gmail.com>
On 13/11/17 11:06, Quan Xu wrote:
> From: Quan Xu <quan.xu0@gmail.com>
>
> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
> in idle path which will poll for a while before we enter the real idle
> state.
>
> In virtualization, idle path includes several heavy operations
> includes timer access(LAPIC timer or TSC deadline timer) which will
> hurt performance especially for latency intensive workload like message
> passing task. The cost is mainly from the vmexit which is a hardware
> context switch between virtual machine and hypervisor. Our solution is
> to poll for a while and do not enter real idle path if we can get the
> schedule event during polling.
>
> Poll may cause the CPU waste so we adopt a smart polling mechanism to
> reduce the useless poll.
>
> Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
> Signed-off-by: Quan Xu <quan.xu0@gmail.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Alok Kataria <akataria@vmware.com>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: virtualization@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org
Hmm, is the idle entry path really so critical to performance that a new
pvops function is necessary? Wouldn't a function pointer, maybe guarded
by a static key, be enough? A further advantage would be that this would
work on other architectures, too.
Juergen
^ permalink raw reply
* [PATCH RFC v3 4/6] Documentation: Add three sysctls for smart idle poll
From: Quan Xu @ 2017-11-13 10:47 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86
Cc: Yang Zhang, Quan Xu
From: Quan Xu <quan.xu0@gmail.com>
To reduce the cost of poll, we introduce three sysctl to control the
poll time when running as a virtual machine with paravirt.
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Signed-off-by: Quan Xu <quan.xu0@gmail.com>
---
Documentation/sysctl/kernel.txt | 35 +++++++++++++++++++++++++++++++++++
arch/x86/kernel/paravirt.c | 4 ++++
include/linux/kernel.h | 6 ++++++
kernel/sysctl.c | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 694968c..30c25fb 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -714,6 +714,41 @@ kernel tries to allocate a number starting from this one.
==============================================================
+paravirt_poll_grow: (X86 only)
+
+Multiplied value to increase the poll time. This is expected to take
+effect only when running as a virtual machine with CONFIG_PARAVIRT
+enabled. This can't bring any benifit on bare mental even with
+CONFIG_PARAVIRT enabled.
+
+By default this value is 2. Possible values to set are in range {2..16}.
+
+==============================================================
+
+paravirt_poll_shrink: (X86 only)
+
+Divided value to reduce the poll time. This is expected to take effect
+only when running as a virtual machine with CONFIG_PARAVIRT enabled.
+This can't bring any benifit on bare mental even with CONFIG_PARAVIRT
+enabled.
+
+By default this value is 2. Possible values to set are in range {2..16}.
+
+==============================================================
+
+paravirt_poll_threshold_ns: (X86 only)
+
+Controls the maximum poll time before entering real idle path. This is
+expected to take effect only when running as a virtual machine with
+CONFIG_PARAVIRT enabled. This can't bring any benifit on bare mental
+even with CONFIG_PARAVIRT enabled.
+
+By default, this value is 0 means not to poll. Possible values to set
+are in range {0..500000}. Change the value to non-zero if running
+latency-bound workloads in a virtual machine.
+
+==============================================================
+
powersave-nap: (PPC only)
If set, Linux-PPC will use the 'nap' mode of powersaving,
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 67cab22..28c74ca 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -317,6 +317,10 @@ struct pv_idle_ops pv_idle_ops = {
.poll = paravirt_nop,
};
+unsigned long paravirt_poll_threshold_ns;
+unsigned int paravirt_poll_shrink = 2;
+unsigned int paravirt_poll_grow = 2;
+
__visible struct pv_irq_ops pv_irq_ops = {
.save_fl = __PV_IS_CALLEE_SAVE(native_save_fl),
.restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4b484ab..0f46846 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -491,6 +491,12 @@ extern __scanf(2, 0)
extern bool crash_kexec_post_notifiers;
+#ifdef CONFIG_PARAVIRT
+extern unsigned long paravirt_poll_threshold_ns;
+extern unsigned int paravirt_poll_shrink;
+extern unsigned int paravirt_poll_grow;
+#endif
+
/*
* panic_cpu is used for synchronizing panic() and crash_kexec() execution. It
* holds a CPU number which is executing panic() currently. A value of
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index d9c31bc..9f194dc 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -135,6 +135,11 @@
static int six_hundred_forty_kb = 640 * 1024;
#endif
+#ifdef CONFIG_PARAVIRT
+static int sixteen = 16;
+static int five_hundred_thousand = 500000;
+#endif
+
/* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
static unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
@@ -1226,6 +1231,35 @@ static int sysrq_sysctl_handler(struct ctl_table *table, int write,
.extra2 = &one,
},
#endif
+#ifdef CONFIG_PARAVIRT
+ {
+ .procname = "paravirt_halt_poll_threshold",
+ .data = ¶virt_poll_threshold_ns,
+ .maxlen = sizeof(unsigned long),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &five_hundred_thousand,
+ },
+ {
+ .procname = "paravirt_halt_poll_grow",
+ .data = ¶virt_poll_grow,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &two,
+ .extra2 = &sixteen,
+ },
+ {
+ .procname = "paravirt_halt_poll_shrink",
+ .data = ¶virt_poll_shrink,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &two,
+ .extra2 = &sixteen,
+ },
+#endif
{ }
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
From: Wei Wang @ 2017-11-13 10:34 UTC (permalink / raw)
To: virtio-dev, linux-kernel, qemu-devel, virtualization, kvm,
linux-mm, mst, mhocko, akpm, mawilcox
Cc: aarcange, yang.zhang.wz, penguin-kernel, liliang.opensource,
willy, amit.shah, quan.xu, cornelia.huck, pbonzini, mgorman
In-Reply-To: <1509696786-1597-7-git-send-email-wei.w.wang@intel.com>
Ping for comments, thanks.
On 11/03/2017 04:13 PM, Wei Wang wrote:
> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
> support of reporting hints of guest free pages to the host via
> virtio-balloon. The host requests the guest to report the free pages by
> sending commands via the virtio-balloon configuration registers.
>
> When the guest starts to report, the first element added to the free page
> vq is a sequence id of the start reporting command. The id is given by
> the host, and it indicates whether the following free pages correspond
> to the command. For example, the host may stop the report and start again
> with a new command id. The obsolete pages for the previous start command
> can be detected by the id dismatching on the host. The id is added to the
> vq using an output buffer, and the free pages are added to the vq using
> input buffer.
>
> Here are some explainations about the added configuration registers:
> - host2guest_cmd: a register used by the host to send commands to the
> guest.
> - guest2host_cmd: written by the guest to ACK to the host about the
> commands that have been received. The host will clear the corresponding
> bits on the host2guest_cmd register. The guest also uses this register
> to send commands to the host (e.g. when finish free page reporting).
> - free_page_cmd_id: the sequence id of the free page report command
> given by the host.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> Signed-off-by: Liang Li <liang.z.li@intel.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> ---
> drivers/virtio/virtio_balloon.c | 234 ++++++++++++++++++++++++++++++++----
> include/uapi/linux/virtio_balloon.h | 11 ++
> 2 files changed, 223 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index b31fc25..4087f04 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -55,7 +55,12 @@ static struct vfsmount *balloon_mnt;
>
> struct virtio_balloon {
> struct virtio_device *vdev;
> - struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> + struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
> +
> + /* Balloon's own wq for cpu-intensive work items */
> + struct workqueue_struct *balloon_wq;
> + /* The free page reporting work item submitted to the balloon wq */
> + struct work_struct report_free_page_work;
>
> /* The balloon servicing is delegated to a freezable workqueue. */
> struct work_struct update_balloon_stats_work;
> @@ -65,6 +70,10 @@ struct virtio_balloon {
> spinlock_t stop_update_lock;
> bool stop_update;
>
> + /* Stop reporting free pages */
> + bool report_free_page_stop;
> + uint32_t free_page_cmd_id;
> +
> /* Waiting for host to ack the pages we released. */
> wait_queue_head_t acked;
>
> @@ -191,6 +200,30 @@ static void send_balloon_page_sg(struct virtio_balloon *vb,
> kick_and_wait(vq, vb->acked);
> }
>
> +static void send_free_page_sg(struct virtqueue *vq, void *addr, uint32_t size)
> +{
> + int err = 0;
> + unsigned int len;
> +
> + /* Detach all the used buffers from the vq */
> + while (virtqueue_get_buf(vq, &len))
> + ;
> +
> + /*
> + * Since this is an optimization feature, losing a couple of free
> + * pages to report isn't important. We simply resturn without adding
> + * the page if the vq is full.
> + */
> + if (vq->num_free) {
> + err = add_one_sg(vq, addr, size);
> + BUG_ON(err);
> + }
> +
> + /* Batch till the vq is full */
> + if (!vq->num_free)
> + virtqueue_kick(vq);
> +}
> +
> /*
> * Send balloon pages in sgs to host. The balloon pages are recorded in the
> * page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
> @@ -495,9 +528,8 @@ static void stats_handle_request(struct virtio_balloon *vb)
> virtqueue_kick(vq);
> }
>
> -static void virtballoon_changed(struct virtio_device *vdev)
> +static void virtballoon_cmd_balloon_memory(struct virtio_balloon *vb)
> {
> - struct virtio_balloon *vb = vdev->priv;
> unsigned long flags;
>
> spin_lock_irqsave(&vb->stop_update_lock, flags);
> @@ -506,6 +538,50 @@ static void virtballoon_changed(struct virtio_device *vdev)
> spin_unlock_irqrestore(&vb->stop_update_lock, flags);
> }
>
> +static void virtballoon_cmd_report_free_page_start(struct virtio_balloon *vb)
> +{
> + unsigned long flags;
> +
> + vb->report_free_page_stop = false;
> + spin_lock_irqsave(&vb->stop_update_lock, flags);
> + if (!vb->stop_update)
> + queue_work(vb->balloon_wq, &vb->report_free_page_work);
> + spin_unlock_irqrestore(&vb->stop_update_lock, flags);
> +}
> +
> +static void virtballoon_changed(struct virtio_device *vdev)
> +{
> + struct virtio_balloon *vb = vdev->priv;
> + u32 host2guest_cmd, guest2host_cmd = 0;
> +
> + if (!virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ)) {
> + virtballoon_cmd_balloon_memory(vb);
> + return;
> + }
> +
> + virtio_cread(vb->vdev, struct virtio_balloon_config, host2guest_cmd,
> + &host2guest_cmd);
> +
> + if (host2guest_cmd & VIRTIO_BALLOON_CMD_BALLOON_MEMORY) {
> + virtballoon_cmd_balloon_memory(vb);
> + guest2host_cmd |= VIRTIO_BALLOON_CMD_BALLOON_MEMORY;
> + }
> +
> + if (host2guest_cmd & VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_START) {
> + virtballoon_cmd_report_free_page_start(vb);
> + guest2host_cmd |= VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_START;
> + }
> +
> + if (host2guest_cmd & VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP) {
> + vb->report_free_page_stop = true;
> + guest2host_cmd |= VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP;
> + }
> +
> + /* Ack to the host about the commands that have been received */
> + virtio_cwrite(vb->vdev, struct virtio_balloon_config, guest2host_cmd,
> + &guest2host_cmd);
> +}
> +
> static inline s64 towards_target(struct virtio_balloon *vb)
> {
> s64 target;
> @@ -597,42 +673,147 @@ static void update_balloon_size_func(struct work_struct *work)
> queue_work(system_freezable_wq, work);
> }
>
> -static int init_vqs(struct virtio_balloon *vb)
> +static bool virtio_balloon_send_free_pages(void *opaque, unsigned long pfn,
> + unsigned long nr_pages)
> {
> - struct virtqueue *vqs[3];
> - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request };
> - static const char * const names[] = { "inflate", "deflate", "stats" };
> - int err, nvqs;
> + struct virtio_balloon *vb = (struct virtio_balloon *)opaque;
> + void *addr = (void *)pfn_to_kaddr(pfn);
> + uint32_t len = nr_pages << PAGE_SHIFT;
> +
> + if (vb->report_free_page_stop)
> + return false;
> +
> + send_free_page_sg(vb->free_page_vq, addr, len);
>
> + return true;
> +}
> +
> +static void report_free_page_end(struct virtio_balloon *vb)
> +{
> + u32 cmd = VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP;
> /*
> - * We expect two virtqueues: inflate and deflate, and
> - * optionally stat.
> + * The host may have already requested to stop the reporting before we
> + * finish, so no need to notify the host in this case.
> */
> - nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2;
> - err = virtio_find_vqs(vb->vdev, nvqs, vqs, callbacks, names, NULL);
> + if (vb->report_free_page_stop)
> + return;
> + vb->report_free_page_stop = true;
> +
> + virtio_cwrite(vb->vdev, struct virtio_balloon_config, guest2host_cmd,
> + &cmd);
> +}
> +
> +static void report_free_page_cmd_id(struct virtio_balloon *vb)
> +{
> + struct scatterlist sg;
> + int err;
> +
> + virtio_cread(vb->vdev, struct virtio_balloon_config, free_page_cmd_id,
> + &vb->free_page_cmd_id);
> + sg_init_one(&sg, &vb->free_page_cmd_id, sizeof(uint32_t));
> + err = virtqueue_add_outbuf(vb->free_page_vq, &sg, 1,
> + &vb->free_page_cmd_id, GFP_KERNEL);
> + BUG_ON(err);
> +}
> +
> +static void report_free_page(struct work_struct *work)
> +{
> + struct virtio_balloon *vb;
> +
> + vb = container_of(work, struct virtio_balloon, report_free_page_work);
> + report_free_page_cmd_id(vb);
> + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
> + /*
> + * The last few free page blocks that were added may not reach the
> + * batch size, but need a kick to notify the device to handle them.
> + */
> + virtqueue_kick(vb->free_page_vq);
> + report_free_page_end(vb);
> +}
> +
> +static int init_vqs(struct virtio_balloon *vb)
> +{
> + struct virtqueue **vqs;
> + vq_callback_t **callbacks;
> + const char **names;
> + struct scatterlist sg;
> + int i, nvqs, err = -ENOMEM;
> +
> + /* Inflateq and deflateq are used unconditionally */
> + nvqs = 2;
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
> + nvqs++;
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ))
> + nvqs++;
> +
> + /* Allocate space for find_vqs parameters */
> + vqs = kcalloc(nvqs, sizeof(*vqs), GFP_KERNEL);
> + if (!vqs)
> + goto err_vq;
> + callbacks = kmalloc_array(nvqs, sizeof(*callbacks), GFP_KERNEL);
> + if (!callbacks)
> + goto err_callback;
> + names = kmalloc_array(nvqs, sizeof(*names), GFP_KERNEL);
> + if (!names)
> + goto err_names;
> +
> + callbacks[0] = balloon_ack;
> + names[0] = "inflate";
> + callbacks[1] = balloon_ack;
> + names[1] = "deflate";
> +
> + i = 2;
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> + callbacks[i] = stats_request;
> + names[i] = "stats";
> + i++;
> + }
> +
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ)) {
> + callbacks[i] = NULL;
> + names[i] = "free_page_vq";
> + }
> +
> + err = vb->vdev->config->find_vqs(vb->vdev, nvqs, vqs, callbacks, names,
> + NULL, NULL);
> if (err)
> - return err;
> + goto err_find;
>
> vb->inflate_vq = vqs[0];
> vb->deflate_vq = vqs[1];
> + i = 2;
> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> - struct scatterlist sg;
> - unsigned int num_stats;
> - vb->stats_vq = vqs[2];
> -
> + vb->stats_vq = vqs[i++];
> /*
> * Prime this virtqueue with one buffer so the hypervisor can
> * use it to signal us later (it can't be broken yet!).
> */
> - num_stats = update_balloon_stats(vb);
> -
> - sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats);
> + sg_init_one(&sg, vb->stats, sizeof(vb->stats));
> if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)
> - < 0)
> - BUG();
> + < 0) {
> + dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n",
> + __func__);
> + goto err_find;
> + }
> virtqueue_kick(vb->stats_vq);
> }
> +
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ))
> + vb->free_page_vq = vqs[i];
> +
> + kfree(names);
> + kfree(callbacks);
> + kfree(vqs);
> return 0;
> +
> +err_find:
> + kfree(names);
> +err_names:
> + kfree(callbacks);
> +err_callback:
> + kfree(vqs);
> +err_vq:
> + return err;
> }
>
> #ifdef CONFIG_BALLOON_COMPACTION
> @@ -761,6 +942,13 @@ static int virtballoon_probe(struct virtio_device *vdev)
> if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_SG))
> xb_init(&vb->page_xb);
>
> + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ)) {
> + vb->balloon_wq = alloc_workqueue("balloon-wq",
> + WQ_FREEZABLE | WQ_CPU_INTENSIVE, 0);
> + INIT_WORK(&vb->report_free_page_work, report_free_page);
> + vb->report_free_page_stop = true;
> + }
> +
> vb->nb.notifier_call = virtballoon_oom_notify;
> vb->nb.priority = VIRTBALLOON_OOM_NOTIFY_PRIORITY;
> err = register_oom_notifier(&vb->nb);
> @@ -825,6 +1013,7 @@ static void virtballoon_remove(struct virtio_device *vdev)
> spin_unlock_irq(&vb->stop_update_lock);
> cancel_work_sync(&vb->update_balloon_size_work);
> cancel_work_sync(&vb->update_balloon_stats_work);
> + cancel_work_sync(&vb->report_free_page_work);
>
> remove_common(vb);
> #ifdef CONFIG_BALLOON_COMPACTION
> @@ -878,6 +1067,7 @@ static unsigned int features[] = {
> VIRTIO_BALLOON_F_STATS_VQ,
> VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> VIRTIO_BALLOON_F_SG,
> + VIRTIO_BALLOON_F_FREE_PAGE_VQ,
> };
>
> static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index 37780a7..b758484 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -35,15 +35,26 @@
> #define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
> #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */
> #define VIRTIO_BALLOON_F_SG 3 /* Use sg instead of PFN lists */
> +#define VIRTIO_BALLOON_F_FREE_PAGE_VQ 4 /* VQ to report free pages */
>
> /* Size of a PFN in the balloon interface. */
> #define VIRTIO_BALLOON_PFN_SHIFT 12
>
> +#define VIRTIO_BALLOON_CMD_BALLOON_MEMORY (1 << 0)
> +#define VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_START (1 << 1)
> +#define VIRTIO_BALLOON_CMD_REPORT_FREE_PAGE_STOP (1 << 2)
> +
> struct virtio_balloon_config {
> /* Number of pages host wants Guest to give up. */
> __u32 num_pages;
> /* Number of pages we've actually got in balloon. */
> __u32 actual;
> + /* Host-to-guest command, readonly by guest */
> + __u32 host2guest_cmd;
> + /* Sequence id of the free_page report command, readonly by guest */
> + __u32 free_page_cmd_id;
> + /* Guest-to-host command */
> + __u32 guest2host_cmd;
> };
>
> #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */
^ permalink raw reply
* [PATCH RFC v3 6/6] KVM guest: introduce smart idle poll algorithm
From: Quan Xu @ 2017-11-13 10:27 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang, Quan Xu, Ingo Molnar, H. Peter Anvin, Paolo Bonzini,
Thomas Gleixner
In-Reply-To: <1510568829-5645-1-git-send-email-quan.xu0@gmail.com>
From: Yang Zhang <yang.zhang.wz@gmail.com>
using smart idle poll to reduce the useless poll when system is idle.
Signed-off-by: Quan Xu <quan.xu0@gmail.com>
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kernel/kvm.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 2a6e402..8bb6d55 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -37,6 +37,7 @@
#include <linux/debugfs.h>
#include <linux/nmi.h>
#include <linux/swait.h>
+#include <linux/tick.h>
#include <asm/timer.h>
#include <asm/cpu.h>
#include <asm/traps.h>
@@ -365,11 +366,57 @@ static void kvm_guest_cpu_init(void)
kvm_register_steal_time();
}
+static unsigned int grow_poll_ns(unsigned int old, unsigned int grow,
+ unsigned int max)
+{
+ unsigned int val;
+
+ /* set base poll time to 10000ns */
+ if (old == 0 && grow)
+ return 10000;
+
+ val = old * grow;
+ if (val > max)
+ val = max;
+
+ return val;
+}
+
+static unsigned int shrink_poll_ns(unsigned int old, unsigned int shrink)
+{
+ if (shrink == 0)
+ return 0;
+
+ return old / shrink;
+}
+
+static void kvm_idle_update_poll_duration(ktime_t idle)
+{
+ unsigned long poll_duration = this_cpu_read(poll_duration_ns);
+
+ /* so far poll duration is based on nohz */
+ if (idle == -1ULL)
+ return;
+
+ if (poll_duration && idle > paravirt_poll_threshold_ns)
+ poll_duration = shrink_poll_ns(poll_duration,
+ paravirt_poll_shrink);
+ else if (poll_duration < paravirt_poll_threshold_ns &&
+ idle < paravirt_poll_threshold_ns)
+ poll_duration = grow_poll_ns(poll_duration, paravirt_poll_grow,
+ paravirt_poll_threshold_ns);
+
+ this_cpu_write(poll_duration_ns, poll_duration);
+}
+
static void kvm_idle_poll(void)
{
unsigned long poll_duration = this_cpu_read(poll_duration_ns);
+ ktime_t idle = tick_nohz_get_last_idle_length();
ktime_t start, cur, stop;
+ kvm_idle_update_poll_duration(idle);
+
start = cur = ktime_get();
stop = ktime_add_ns(ktime_get(), poll_duration);
--
1.7.1
^ permalink raw reply related
* [PATCH RFC v3 5/6] tick: get duration of the last idle loop
From: Quan Xu @ 2017-11-13 10:27 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang, Frederic Weisbecker, Thomas Gleixner, Quan Xu,
Ingo Molnar
In-Reply-To: <1510568829-5645-1-git-send-email-quan.xu0@gmail.com>
From: Quan Xu <quan.xu0@gmail.com>
the last idle loop is from tick_nohz_idle_enter to tick_nohz_idle_exit.
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Signed-off-by: Quan Xu <quan.xu0@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org
---
include/linux/tick.h | 2 ++
kernel/time/tick-sched.c | 11 +++++++++++
kernel/time/tick-sched.h | 3 +++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index cf413b3..77ae46d 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -118,6 +118,7 @@ enum tick_dep_bits {
extern void tick_nohz_idle_exit(void);
extern void tick_nohz_irq_exit(void);
extern ktime_t tick_nohz_get_sleep_length(void);
+extern ktime_t tick_nohz_get_last_idle_length(void);
extern unsigned long tick_nohz_get_idle_calls(void);
extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
@@ -127,6 +128,7 @@ enum tick_dep_bits {
static inline void tick_nohz_idle_enter(void) { }
static inline void tick_nohz_idle_exit(void) { }
+static ktime_t tick_nohz_get_last_idle_length(void) { return -1; }
static inline ktime_t tick_nohz_get_sleep_length(void)
{
return NSEC_PER_SEC / HZ;
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index c7a899c..65c9cc0 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -548,6 +548,7 @@ static void tick_nohz_update_jiffies(ktime_t now)
else
ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
ts->idle_entrytime = now;
+ ts->idle_length = delta;
}
if (last_update_time)
@@ -998,6 +999,16 @@ void tick_nohz_irq_exit(void)
}
/**
+ * tick_nohz_get_last_idle_length - return the length of the last idle loop
+ */
+ktime_t tick_nohz_get_last_idle_length(void)
+{
+ struct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched);
+
+ return ts->idle_length;
+}
+
+/**
* tick_nohz_get_sleep_length - return the length of the current sleep
*
* Called from power state control code with interrupts disabled
diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
index 954b43d..2630cf9 100644
--- a/kernel/time/tick-sched.h
+++ b/kernel/time/tick-sched.h
@@ -39,6 +39,8 @@ enum tick_nohz_mode {
* @idle_sleeptime: Sum of the time slept in idle with sched tick stopped
* @iowait_sleeptime: Sum of the time slept in idle with sched tick stopped, with IO outstanding
* @sleep_length: Duration of the current idle sleep
+ * @idle_length: Duration of the last idle loop is from
+ * tick_nohz_idle_enter to tick_nohz_idle_exit.
* @do_timer_lst: CPU was the last one doing do_timer before going idle
*/
struct tick_sched {
@@ -59,6 +61,7 @@ struct tick_sched {
ktime_t idle_sleeptime;
ktime_t iowait_sleeptime;
ktime_t sleep_length;
+ ktime_t idle_length;
unsigned long last_jiffies;
u64 next_timer;
ktime_t idle_expires;
--
1.7.1
^ permalink raw reply related
* [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
From: Quan Xu @ 2017-11-13 10:06 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang, Len Brown, Quan Xu, Tom Lendacky, Peter Zijlstra,
Kyle Huey, Ingo Molnar, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, Thomas Gleixner, Tobias Klauser
In-Reply-To: <1510567565-5118-1-git-send-email-quan.xu0@gmail.com>
From: Yang Zhang <yang.zhang.wz@gmail.com>
Implement a generic idle poll which resembles the functionality
found in arch/. Provide weak arch_cpu_idle_poll function which
can be overridden by the architecture code if needed.
Interrupts arrive which may not cause a reschedule in idle loops.
In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry
for interrupts and VM-exit immediately. Also this becomes more
expensive than bare metal. Add a generic idle poll before enter
real idle path. When a reschedule event is pending, we can bypass
the real idle path.
Signed-off-by: Quan Xu <quan.xu0@gmail.com>
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Kyle Huey <me@kylehuey.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Tobias Klauser <tklauser@distanz.ch>
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kernel/process.c | 7 +++++++
kernel/sched/idle.c | 2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index c676853..f7db8b5 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -333,6 +333,13 @@ void arch_cpu_idle(void)
x86_idle();
}
+#ifdef CONFIG_PARAVIRT
+void arch_cpu_idle_poll(void)
+{
+ paravirt_idle_poll();
+}
+#endif
+
/*
* We use this if we don't have any better idle routine..
*/
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 257f4f0..df7c422 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -74,6 +74,7 @@ static noinline int __cpuidle cpu_idle_poll(void)
}
/* Weak implementations for optional arch specific functions */
+void __weak arch_cpu_idle_poll(void) { }
void __weak arch_cpu_idle_prepare(void) { }
void __weak arch_cpu_idle_enter(void) { }
void __weak arch_cpu_idle_exit(void) { }
@@ -219,6 +220,7 @@ static void do_idle(void)
*/
__current_set_polling();
+ arch_cpu_idle_poll();
quiet_vmstat();
tick_nohz_idle_enter();
--
1.7.1
^ permalink raw reply related
* [PATCH RFC v3 2/6] KVM guest: register kvm_idle_poll for pv_idle_ops
From: Quan Xu @ 2017-11-13 10:06 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang, Quan Xu, Radim Krčmář, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Thomas Gleixner
In-Reply-To: <1510567565-5118-1-git-send-email-quan.xu0@gmail.com>
From: Quan Xu <quan.xu0@gmail.com>
Although smart idle poll has nothing to do with paravirt, it can
not bring any benifit to native. So we only enable it when Linux
runs as a KVM guest( also it can extend to other hypervisor like
Xen, HyperV and VMware).
Introduce per-CPU variable poll_duration_ns to control the max
poll time.
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Signed-off-by: Quan Xu <quan.xu0@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kernel/kvm.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8bb9594..2a6e402 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -75,6 +75,7 @@ static int parse_no_kvmclock_vsyscall(char *arg)
early_param("no-kvmclock-vsyscall", parse_no_kvmclock_vsyscall);
+static DEFINE_PER_CPU(unsigned long, poll_duration_ns);
static DEFINE_PER_CPU(struct kvm_vcpu_pv_apf_data, apf_reason) __aligned(64);
static DEFINE_PER_CPU(struct kvm_steal_time, steal_time) __aligned(64);
static int has_steal_clock = 0;
@@ -364,6 +365,29 @@ static void kvm_guest_cpu_init(void)
kvm_register_steal_time();
}
+static void kvm_idle_poll(void)
+{
+ unsigned long poll_duration = this_cpu_read(poll_duration_ns);
+ ktime_t start, cur, stop;
+
+ start = cur = ktime_get();
+ stop = ktime_add_ns(ktime_get(), poll_duration);
+
+ do {
+ if (need_resched())
+ break;
+ cur = ktime_get();
+ } while (ktime_before(cur, stop));
+}
+
+static void kvm_guest_idle_init(void)
+{
+ if (!kvm_para_available())
+ return;
+
+ pv_idle_ops.poll = kvm_idle_poll;
+}
+
static void kvm_pv_disable_apf(void)
{
if (!__this_cpu_read(apf_reason.enabled))
@@ -499,6 +523,8 @@ void __init kvm_guest_init(void)
kvm_guest_cpu_init();
#endif
+ kvm_guest_idle_init();
+
/*
* Hard lockup detection is enabled by default. Disable it, as guests
* can get false positives too easily, for example if the host is
--
1.7.1
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops
From: Quan Xu @ 2017-11-13 10:06 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang, Juergen Gross, Quan Xu, Rusty Russell, Ingo Molnar,
H. Peter Anvin, Alok Kataria, Thomas Gleixner
In-Reply-To: <1510567565-5118-1-git-send-email-quan.xu0@gmail.com>
From: Quan Xu <quan.xu0@gmail.com>
So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we enter the real idle
state.
In virtualization, idle path includes several heavy operations
includes timer access(LAPIC timer or TSC deadline timer) which will
hurt performance especially for latency intensive workload like message
passing task. The cost is mainly from the vmexit which is a hardware
context switch between virtual machine and hypervisor. Our solution is
to poll for a while and do not enter real idle path if we can get the
schedule event during polling.
Poll may cause the CPU waste so we adopt a smart polling mechanism to
reduce the useless poll.
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Signed-off-by: Quan Xu <quan.xu0@gmail.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Alok Kataria <akataria@vmware.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
arch/x86/include/asm/paravirt.h | 5 +++++
arch/x86/include/asm/paravirt_types.h | 6 ++++++
arch/x86/kernel/paravirt.c | 6 ++++++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index fd81228..3c83727 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -198,6 +198,11 @@ static inline unsigned long long paravirt_read_pmc(int counter)
#define rdpmcl(counter, val) ((val) = paravirt_read_pmc(counter))
+static inline void paravirt_idle_poll(void)
+{
+ PVOP_VCALL0(pv_idle_ops.poll);
+}
+
static inline void paravirt_alloc_ldt(struct desc_struct *ldt, unsigned entries)
{
PVOP_VCALL2(pv_cpu_ops.alloc_ldt, ldt, entries);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 10cc3b9..95c0e3e 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -313,6 +313,10 @@ struct pv_lock_ops {
struct paravirt_callee_save vcpu_is_preempted;
} __no_randomize_layout;
+struct pv_idle_ops {
+ void (*poll)(void);
+} __no_randomize_layout;
+
/* This contains all the paravirt structures: we get a convenient
* number for each function using the offset which we use to indicate
* what to patch. */
@@ -323,6 +327,7 @@ struct paravirt_patch_template {
struct pv_irq_ops pv_irq_ops;
struct pv_mmu_ops pv_mmu_ops;
struct pv_lock_ops pv_lock_ops;
+ struct pv_idle_ops pv_idle_ops;
} __no_randomize_layout;
extern struct pv_info pv_info;
@@ -332,6 +337,7 @@ struct paravirt_patch_template {
extern struct pv_irq_ops pv_irq_ops;
extern struct pv_mmu_ops pv_mmu_ops;
extern struct pv_lock_ops pv_lock_ops;
+extern struct pv_idle_ops pv_idle_ops;
#define PARAVIRT_PATCH(x) \
(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 19a3e8f..67cab22 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -128,6 +128,7 @@ unsigned paravirt_patch_jmp(void *insnbuf, const void *target,
#ifdef CONFIG_PARAVIRT_SPINLOCKS
.pv_lock_ops = pv_lock_ops,
#endif
+ .pv_idle_ops = pv_idle_ops,
};
return *((void **)&tmpl + type);
}
@@ -312,6 +313,10 @@ struct pv_time_ops pv_time_ops = {
.steal_clock = native_steal_clock,
};
+struct pv_idle_ops pv_idle_ops = {
+ .poll = paravirt_nop,
+};
+
__visible struct pv_irq_ops pv_irq_ops = {
.save_fl = __PV_IS_CALLEE_SAVE(native_save_fl),
.restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
@@ -463,3 +468,4 @@ struct pv_mmu_ops pv_mmu_ops __ro_after_init = {
EXPORT_SYMBOL (pv_mmu_ops);
EXPORT_SYMBOL_GPL(pv_info);
EXPORT_SYMBOL (pv_irq_ops);
+EXPORT_SYMBOL (pv_idle_ops);
--
1.7.1
^ permalink raw reply related
* [PATCH RFC v3 0/6] x86/idle: add halt poll support
From: Quan Xu @ 2017-11-13 10:05 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang
From: Yang Zhang <yang.zhang.wz@gmail.com>
Some latency-intensive workload have seen obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost I have seen is
inside idle path.
This patch introduces a new mechanism to poll for a while before
entering idle state. If schedule is needed during poll, then we
don't need to goes through the heavy overhead path.
Here is the data we get when running benchmark contextswitch to measure
the latency(lower is better):
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
3402.9 ns/ctxsw -- 199.8 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
halt_poll_threshold=10000 -- 1151.4 ns/ctxsw -- 200.1 %CPU
halt_poll_threshold=20000 -- 1149.7 ns/ctxsw -- 199.9 %CPU
halt_poll_threshold=30000 -- 1151.0 ns/ctxsw -- 199.9 %CPU
halt_poll_threshold=40000 -- 1155.4 ns/ctxsw -- 199.3 %CPU
halt_poll_threshold=50000 -- 1161.0 ns/ctxsw -- 200.0 %CPU
halt_poll_threshold=100000 -- 1163.8 ns/ctxsw -- 200.4 %CPU
halt_poll_threshold=300000 -- 1159.4 ns/ctxsw -- 201.9 %CPU
halt_poll_threshold=500000 -- 1163.5 ns/ctxsw -- 205.5 %CPU
3. w/ kvm dynamic poll:
halt_poll_ns=10000 -- 3470.5 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=20000 -- 3273.0 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=30000 -- 3628.7 ns/ctxsw -- 199.4 %CPU
halt_poll_ns=40000 -- 2280.6 ns/ctxsw -- 199.5 %CPU
halt_poll_ns=50000 -- 3200.3 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=100000 -- 2186.6 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=300000 -- 3178.7 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=500000 -- 3505.4 ns/ctxsw -- 199.7 %CPU
4. w/patch and w/ kvm dynamic poll:
halt_poll_ns=10000 & halt_poll_threshold=10000 -- 1155.5 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=20000 -- 1165.6 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=30000 -- 1161.1 ns/ctxsw -- 200.0 %CPU
halt_poll_ns=20000 & halt_poll_threshold=10000 -- 1158.1 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=20000 & halt_poll_threshold=20000 -- 1161.0 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=20000 & halt_poll_threshold=30000 -- 1163.7 ns/ctxsw -- 199.9 %CPU
halt_poll_ns=30000 & halt_poll_threshold=10000 -- 1158.7 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=30000 & halt_poll_threshold=20000 -- 1153.8 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=30000 & halt_poll_threshold=30000 -- 1155.1 ns/ctxsw -- 199.8 %CPU
5. idle=poll
3957.57 ns/ctxsw -- 999.4%CPU
Here is the data we get when running benchmark netperf:
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
29031.6 bit/s -- 76.1 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
halt_poll_threshold=10000 -- 29021.7 bit/s -- 105.1 %CPU
halt_poll_threshold=20000 -- 33463.5 bit/s -- 128.2 %CPU
halt_poll_threshold=30000 -- 34436.4 bit/s -- 127.8 %CPU
halt_poll_threshold=40000 -- 35563.3 bit/s -- 129.6 %CPU
halt_poll_threshold=50000 -- 35787.7 bit/s -- 129.4 %CPU
halt_poll_threshold=100000 -- 35477.7 bit/s -- 130.0 %CPU
halt_poll_threshold=300000 -- 35730.0 bit/s -- 132.4 %CPU
halt_poll_threshold=500000 -- 34978.4 bit/s -- 134.2 %CPU
3. w/ kvm dynamic poll:
halt_poll_ns=10000 -- 28849.8 bit/s -- 75.2 %CPU
halt_poll_ns=20000 -- 29004.8 bit/s -- 76.1 %CPU
halt_poll_ns=30000 -- 35662.0 bit/s -- 199.7 %CPU
halt_poll_ns=40000 -- 35874.8 bit/s -- 187.5 %CPU
halt_poll_ns=50000 -- 35603.1 bit/s -- 199.8 %CPU
halt_poll_ns=100000 -- 35588.8 bit/s -- 200.0 %CPU
halt_poll_ns=300000 -- 35912.4 bit/s -- 200.0 %CPU
halt_poll_ns=500000 -- 35735.6 bit/s -- 200.0 %CPU
4. w/patch and w/ kvm dynamic poll:
halt_poll_ns=10000 & halt_poll_threshold=10000 -- 29427.9 bit/s -- 107.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=20000 -- 33048.4 bit/s -- 128.1 %CPU
halt_poll_ns=10000 & halt_poll_threshold=30000 -- 35129.8 bit/s -- 129.1 %CPU
halt_poll_ns=20000 & halt_poll_threshold=10000 -- 31091.3 bit/s -- 130.3 %CPU
halt_poll_ns=20000 & halt_poll_threshold=20000 -- 33587.9 bit/s -- 128.9 %CPU
halt_poll_ns=20000 & halt_poll_threshold=30000 -- 35532.9 bit/s -- 129.1 %CPU
halt_poll_ns=30000 & halt_poll_threshold=10000 -- 35633.1 bit/s -- 199.4 %CPU
halt_poll_ns=30000 & halt_poll_threshold=20000 -- 42225.3 bit/s -- 198.7 %CPU
halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU
5. idle=poll
37081.7 bit/s -- 998.1 %CPU
---
V2 -> V3:
- move poll update into arch/. in v3, poll update is based on duration of the
last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit,
and try our best not to interfere with scheduler/idle code. (This seems
not to follow Peter's v2 comment, however we had a f2f discussion about it
in Prague.)
- enhance patch desciption.
- enhance Documentation and sysctls.
- test with IRQ_TIMINGS related code, which seems not working so far.
V1 -> V2:
- integrate the smart halt poll into paravirt code
- use idle_stamp instead of check_poll
- since it hard to get whether vcpu is the only task in pcpu, so we
don't consider it in this series.(May improve it in future)
---
Quan Xu (4):
x86/paravirt: Add pv_idle_ops to paravirt ops
KVM guest: register kvm_idle_poll for pv_idle_ops
Documentation: Add three sysctls for smart idle poll
tick: get duration of the last idle loop
Yang Zhang (2):
sched/idle: Add a generic poll before enter real idle path
KVM guest: introduce smart idle poll algorithm
Documentation/sysctl/kernel.txt | 35 ++++++++++++++++
arch/x86/include/asm/paravirt.h | 5 ++
arch/x86/include/asm/paravirt_types.h | 6 +++
arch/x86/kernel/kvm.c | 73 +++++++++++++++++++++++++++++++++
arch/x86/kernel/paravirt.c | 10 +++++
arch/x86/kernel/process.c | 7 +++
include/linux/kernel.h | 6 +++
include/linux/tick.h | 2 +
kernel/sched/idle.c | 2 +
kernel/sysctl.c | 34 +++++++++++++++
kernel/time/tick-sched.c | 11 +++++
kernel/time/tick-sched.h | 3 +
12 files changed, 194 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH RFC v3 0/6] x86/idle: add halt poll support
From: Quan Xu @ 2017-11-13 8:16 UTC (permalink / raw)
To: kvm, linux-doc, linux-fsdevel, linux-kernel, virtualization, x86,
xen-devel
Cc: Yang Zhang
From: Yang Zhang <yang.zhang.wz@gmail.com>
Some latency-intensive workload have seen obviously performance
drop when running inside VM. The main reason is that the overhead
is amplified when running inside VM. The most cost I have seen is
inside idle path.
This patch introduces a new mechanism to poll for a while before
entering idle state. If schedule is needed during poll, then we
don't need to goes through the heavy overhead path.
Here is the data we get when running benchmark contextswitch to measure
the latency(lower is better):
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
3402.9 ns/ctxsw -- 199.8 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
halt_poll_threshold=10000 -- 1151.4 ns/ctxsw -- 200.1 %CPU
halt_poll_threshold=20000 -- 1149.7 ns/ctxsw -- 199.9 %CPU
halt_poll_threshold=30000 -- 1151.0 ns/ctxsw -- 199.9 %CPU
halt_poll_threshold=40000 -- 1155.4 ns/ctxsw -- 199.3 %CPU
halt_poll_threshold=50000 -- 1161.0 ns/ctxsw -- 200.0 %CPU
halt_poll_threshold=100000 -- 1163.8 ns/ctxsw -- 200.4 %CPU
halt_poll_threshold=300000 -- 1159.4 ns/ctxsw -- 201.9 %CPU
halt_poll_threshold=500000 -- 1163.5 ns/ctxsw -- 205.5 %CPU
3. w/ kvm dynamic poll:
halt_poll_ns=10000 -- 3470.5 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=20000 -- 3273.0 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=30000 -- 3628.7 ns/ctxsw -- 199.4 %CPU
halt_poll_ns=40000 -- 2280.6 ns/ctxsw -- 199.5 %CPU
halt_poll_ns=50000 -- 3200.3 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=100000 -- 2186.6 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=300000 -- 3178.7 ns/ctxsw -- 199.6 %CPU
halt_poll_ns=500000 -- 3505.4 ns/ctxsw -- 199.7 %CPU
4. w/patch and w/ kvm dynamic poll:
halt_poll_ns=10000 & halt_poll_threshold=10000 -- 1155.5 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=20000 -- 1165.6 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=30000 -- 1161.1 ns/ctxsw -- 200.0 %CPU
halt_poll_ns=20000 & halt_poll_threshold=10000 -- 1158.1 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=20000 & halt_poll_threshold=20000 -- 1161.0 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=20000 & halt_poll_threshold=30000 -- 1163.7 ns/ctxsw -- 199.9 %CPU
halt_poll_ns=30000 & halt_poll_threshold=10000 -- 1158.7 ns/ctxsw -- 199.7 %CPU
halt_poll_ns=30000 & halt_poll_threshold=20000 -- 1153.8 ns/ctxsw -- 199.8 %CPU
halt_poll_ns=30000 & halt_poll_threshold=30000 -- 1155.1 ns/ctxsw -- 199.8 %CPU
5. idle=poll
3957.57 ns/ctxsw -- 999.4%CPU
Here is the data we get when running benchmark netperf:
1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
29031.6 bit/s -- 76.1 %CPU
2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
halt_poll_threshold=10000 -- 29021.7 bit/s -- 105.1 %CPU
halt_poll_threshold=20000 -- 33463.5 bit/s -- 128.2 %CPU
halt_poll_threshold=30000 -- 34436.4 bit/s -- 127.8 %CPU
halt_poll_threshold=40000 -- 35563.3 bit/s -- 129.6 %CPU
halt_poll_threshold=50000 -- 35787.7 bit/s -- 129.4 %CPU
halt_poll_threshold=100000 -- 35477.7 bit/s -- 130.0 %CPU
halt_poll_threshold=300000 -- 35730.0 bit/s -- 132.4 %CPU
halt_poll_threshold=500000 -- 34978.4 bit/s -- 134.2 %CPU
3. w/ kvm dynamic poll:
halt_poll_ns=10000 -- 28849.8 bit/s -- 75.2 %CPU
halt_poll_ns=20000 -- 29004.8 bit/s -- 76.1 %CPU
halt_poll_ns=30000 -- 35662.0 bit/s -- 199.7 %CPU
halt_poll_ns=40000 -- 35874.8 bit/s -- 187.5 %CPU
halt_poll_ns=50000 -- 35603.1 bit/s -- 199.8 %CPU
halt_poll_ns=100000 -- 35588.8 bit/s -- 200.0 %CPU
halt_poll_ns=300000 -- 35912.4 bit/s -- 200.0 %CPU
halt_poll_ns=500000 -- 35735.6 bit/s -- 200.0 %CPU
4. w/patch and w/ kvm dynamic poll:
halt_poll_ns=10000 & halt_poll_threshold=10000 -- 29427.9 bit/s -- 107.8 %CPU
halt_poll_ns=10000 & halt_poll_threshold=20000 -- 33048.4 bit/s -- 128.1 %CPU
halt_poll_ns=10000 & halt_poll_threshold=30000 -- 35129.8 bit/s -- 129.1 %CPU
halt_poll_ns=20000 & halt_poll_threshold=10000 -- 31091.3 bit/s -- 130.3 %CPU
halt_poll_ns=20000 & halt_poll_threshold=20000 -- 33587.9 bit/s -- 128.9 %CPU
halt_poll_ns=20000 & halt_poll_threshold=30000 -- 35532.9 bit/s -- 129.1 %CPU
halt_poll_ns=30000 & halt_poll_threshold=10000 -- 35633.1 bit/s -- 199.4 %CPU
halt_poll_ns=30000 & halt_poll_threshold=20000 -- 42225.3 bit/s -- 198.7 %CPU
halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU
5. idle=poll
37081.7 bit/s -- 998.1 %CPU
---
V2 -> V3:
- move poll update into arch/. in v3, poll update is based on duration of the
last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit,
and try our best not to interfere with scheduler/idle code. (This seems
not to follow Peter's v2 comment, however we had a f2f discussion about it
in Prague.)
- enhance patch desciption.
- enhance Documentation and sysctls.
- test with IRQ_TIMINGS related code, which seems not working so far.
V1 -> V2:
- integrate the smart halt poll into paravirt code
- use idle_stamp instead of check_poll
- since it hard to get whether vcpu is the only task in pcpu, so we
don't consider it in this series.(May improve it in future)
---
Quan Xu (4):
x86/paravirt: Add pv_idle_ops to paravirt ops
KVM guest: register kvm_idle_poll for pv_idle_ops
Documentation: Add three sysctls for smart idle poll
tick: get duration of the last idle loop
Yang Zhang (2):
sched/idle: Add a generic poll before enter real idle path
KVM guest: introduce smart idle poll algorithm
Documentation/sysctl/kernel.txt | 35 ++++++++++++++++
arch/x86/include/asm/paravirt.h | 5 ++
arch/x86/include/asm/paravirt_types.h | 6 +++
arch/x86/kernel/kvm.c | 73 +++++++++++++++++++++++++++++++++
arch/x86/kernel/paravirt.c | 10 +++++
arch/x86/kernel/process.c | 7 +++
include/linux/kernel.h | 6 +++
include/linux/tick.h | 2 +
kernel/sched/idle.c | 2 +
kernel/sysctl.c | 34 +++++++++++++++
kernel/time/tick-sched.c | 11 +++++
kernel/time/tick-sched.h | 3 +
12 files changed, 194 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH net-next V2] vhost_net: conditionally enable tx polling
From: Jason Wang @ 2017-11-13 3:45 UTC (permalink / raw)
To: mst, jasowang, kvm, virtualization, netdev, linux-kernel
Cc: Matthew Rosato, Wei Xu
We always poll tx for socket, this is sub optimal since this will
slightly increase the waitqueue traversing time and more important,
vhost could not benefit from commit 9e641bdcfa4e ("net-tun:
restructure tun_do_read for better sleep/wakeup efficiency") even if
we've stopped rx polling during handle_rx(), tx poll were still left
in the waitqueue.
Pktgen from a remote host to VM over mlx4 on two 2.00GHz Xeon E5-2650
shows 11.7% improvements on rx PPS. (from 1.28Mpps to 1.44Mpps)
Cc: Wei Xu <wexu@redhat.com>
Cc: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V1:
- don't try to disable tx polling during start
- poll tx on error unconditonally
---
drivers/vhost/net.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 68677d9..8d626d7 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -471,6 +471,7 @@ static void handle_tx(struct vhost_net *net)
goto out;
vhost_disable_notify(&net->dev, vq);
+ vhost_net_disable_vq(net, vq);
hdr_size = nvq->vhost_hlen;
zcopy = nvq->ubufs;
@@ -556,6 +557,7 @@ static void handle_tx(struct vhost_net *net)
% UIO_MAXIOV;
}
vhost_discard_vq_desc(vq, 1);
+ vhost_net_enable_vq(net, vq);
break;
}
if (err != len)
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox