Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1573068
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [patch 0/3] KVM CPU frequency change hypercalls |
| Date | 2017-02-03 14:00 +0100 |
| Message-ID | <t6LD4-1GR-7@gated-at.bofh.it> (permalink) |
| References | <t6tPQ-77C-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thursday, February 02, 2017 03:47:55 PM Marcelo Tosatti wrote: > Implement KVM hypercalls for the guest > to issue frequency changes. > > Current situation with DPDK and frequency changes is as follows: > An algorithm in the guest decides when to increase/decrease > frequency based on the queue length of the device. > > On the host, a power manager daemon is used to listen for > frequency change requests (on another core) and issue these > requests. > > However frequency changes are performance sensitive events because: > On a change from low load condition to max load condition, > the frequency should be raised as soon as possible. > Sending a virtio-serial notification to another pCPU, > waiting for that pCPU to initiate an IPI to the requestor pCPU > to change frequency, is slower and more cache costly than > a direct hypercall to host to switch the frequency. > > If the pCPU where the power manager daemon is running > is not busy spinning on requests from the isolated DPDK vcpus, > there is also the cost of HLT wakeup for that pCPU. > > Moreover, the daemon serves multiple VMs, meaning that > the scheme is subject to additional delays from > queueing of power change requests from VMs. > > A direct hypercall from userspace is the fastest most direct > method for the guest to change frequency and does not suffer > from the issues above. > > The usage scenario for this hypercalls is for pinned vCPUs <-> pCPUs. Any chance to CC this to linux-pm in the future? That would help the review quite a bit. Thanks, Rafael
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[patch 0/3] KVM CPU frequency change hypercalls Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-02 19:00 +0100
[patch 1/3] cpufreq: implement min/max/up/down functions Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-02 19:00 +0100
Re: [patch 1/3] cpufreq: implement min/max/up/down functions Viresh Kumar <viresh.kumar@linaro.org> - 2017-02-03 05:10 +0100
[patch 2/3] KVM: x86: introduce ioctl to allow frequency hypercalls Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-02 19:00 +0100
Re: [patch 2/3] KVM: x86: introduce ioctl to allow frequency hypercalls Radim Krcmar <rkrcmar@redhat.com> - 2017-02-03 18:10 +0100
Re: [patch 3/3] KVM: x86: frequency change hypercalls Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-02 19:10 +0100
[patch 3/3] KVM: x86: frequency change hypercalls Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-02 19:10 +0100
Re: [patch 3/3] KVM: x86: frequency change hypercalls Radim Krcmar <rkrcmar@redhat.com> - 2017-02-03 18:50 +0100
Re: [patch 3/3] KVM: x86: frequency change hypercalls Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-03 19:30 +0100
Re: [patch 3/3] KVM: x86: frequency change hypercalls Radim Krcmar <rkrcmar@redhat.com> - 2017-02-03 20:30 +0100
Re: [patch 0/3] KVM CPU frequency change hypercalls "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-02-03 14:00 +0100
Re: [patch 0/3] KVM CPU frequency change hypercalls Radim Krcmar <rkrcmar@redhat.com> - 2017-02-03 17:50 +0100
Re: [patch 0/3] KVM CPU frequency change hypercalls Marcelo Tosatti <mtosatti@redhat.com> - 2017-02-03 19:30 +0100
Re: [patch 0/3] KVM CPU frequency change hypercalls Radim Krcmar <rkrcmar@redhat.com> - 2017-02-03 20:10 +0100
csiph-web