From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function Date: Tue, 04 Jan 2011 12:53:33 -0500 Message-ID: <4D235E9D.1040603@redhat.com> References: <20110103162637.29f23c40@annuminas.surriel.com> <20110103162918.577a9620@annuminas.surriel.com> <4D234E60.3010804@redhat.com> <1294160890.2016.171.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hillf Danton , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Avi Kiviti , Srivatsa Vaddagiri , Mike Galbraith , Chris Wright To: Peter Zijlstra Return-path: In-Reply-To: <1294160890.2016.171.camel@laptop> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 01/04/2011 12:08 PM, Peter Zijlstra wrote: > On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote: >> Where is the yield_to callback in the patch for RT schedule class? >> If @p is RT, what could you do? > > RT guests are a pipe dream, you first need to get the hypervisor (kvm in > this case) to be RT, which it isn't. Then you either need to very > statically set-up the host and the guest scheduling constraints (not > possible with RR/FIFO) or have a complete paravirt RT scheduler which > communicates its requirements to the host. There's a limited use case. One host can have a few RT guests, say a host with 8 CPUs can have up to 6 or 7 RT VCPUs. Those guests get top priority. The host can then have some other, low priority, guests that scavenge remaining CPU time. In this case, no yield_to is required for RT guests, because they do not do overcommit. -- All rights reversed