linux-kernel - Re: [PATCH 4/4] KVM guest implementation

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 31 Aug 2021 09:21:11 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Tianqiang Xu <skyele@...u.edu.cn>
Cc:     x86@...nel.org, pbonzini@...hat.com, seanjc@...gle.com,
        vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
        joro@...tes.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, kvm@...r.kernel.org, hpa@...or.com,
        jarkko@...nel.org, dave.hansen@...ux.intel.com,
        linux-kernel@...r.kernel.org, linux-sgx@...r.kernel.org
Subject: Re: [PATCH 4/4] KVM guest implementation

On Tue, Aug 31, 2021 at 09:59:19AM +0800, Tianqiang Xu wrote:
> Guest OS uses 'is_idle' field of kvm_steal_time to know if a pCPU
> is idle and decides whether to schedule a task to a preempted vCPU
> or not. If the pCPU is idle, scheduling a task to this pCPU will
> improve cpu utilization. If not, avoiding scheduling a task to this
> preempted vCPU can avoid host/guest switch, hence improving performance.
> 
> Guest OS invokes available_idle_cpu_sched() to get the value of
> 'is_idle' field of kvm_steal_time.
> 
> Other modules in kernel except kernel/sched/fair.c which invokes
> available_idle_cpu() is left unchanged, because other modules in
> kernel need the semantic provided by 'preempted' field of kvm_steal_time.

> ---
>  kernel/sched/fair.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)

Goes and replaces every single available_idle_cpu() in fair with the new
function that doesn't consider vCPU preemption.

So what do you reckon now happens in the oversubscribed virt scenario
where each CPU has multiple vCPUs?