[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YS3YZ+0pJjNL4ouE@hirez.programming.kicks-ass.net>
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?
Powered by blists - more mailing lists