From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function Date: Tue, 04 Jan 2011 18:22:17 +0100 Message-ID: <1294161737.2016.177.camel@laptop> 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" Content-Transfer-Encoding: 8BIT Cc: Rik van Riel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Avi Kiviti , Srivatsa Vaddagiri , Mike Galbraith , Chris Wright To: Hillf Danton Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Wed, 2011-01-05 at 01:12 +0800, Hillf Danton wrote: > On Wed, Jan 5, 2011 at 1:08 AM, 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. > > > Even guest is not RT, you could not prevent it from being preempted by > RT task which has nothing to do guests. Sure, but yield_to() being a NOP for RT tasks is perfectly fine. Pretty much all yield*() usage is a bug anyway.