linux-kernel - Re: [patch 0/3] KVM CPU frequency change hypercalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1585277.2ucOxC55qH@aspire.rjw.lan>
Date:   Fri, 03 Feb 2017 13:50:17 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Marcelo Tosatti <mtosatti@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krcmar <rkrcmar@...hat.com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [patch 0/3] KVM CPU frequency change hypercalls

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