Re: [Fwd: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function]

[Hillf Danton]

On Wed, Jan 5, 2011 at 5:41 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Wed, 2011-01-05 at 00:38 +0100, Tommaso Cucinotta wrote:
>> Il 04/01/2011 19:15, Dario Faggioli ha scritto:
>> >
>> > -------- Forwarded Message --------
>> > From: Peter Zijlstra<a.p.zijlstra@xxxxxxxxx>
>> > To: Rik van Riel<riel@xxxxxxxxxx>
>> > Cc: Hillf Danton<dhillf@xxxxxxxxx>,kvm@xxxxxxxxxxxxxxx,
>> > linux-kernel@xxxxxxxxxxxxxxx, Avi Kiviti<avi@xxxxxxxxxx>, Srivatsa
>> > Vaddagiri<vatsa@xxxxxxxxxxxxxxxxxx>, Mike Galbraith<efault@xxxxxx>,
>> > Chris Wright<chrisw@xxxxxxxxxxxx>
>> > Subject: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function
>> > Date: Tue, 04 Jan 2011 19:05:54 +0100
>> > RT guests don't make sense, there's nowhere near enough infrastructure
>> > for that to work well.
>> >
>> > I'd argue that KVM running with RT priority is a bug.
>> Peter, can I ask why did you state that ? In the IRMOS project, we
>> are just deploying KVM VMs by using the Fabio's real-time scheduler
>> (for others, a.k.a., the Fabio's EDF throttling patch, or IRMOS RT
>> scheduler)
>> in order to let the VMs get precise CPU scheduling guarantees by the
>> kernel. So, in this context we do have KVM running at RT priority, and
>> we do have experimental results showing how this can improve stability
>> of performance of the hosted guest VMs.
>> Of course, don't misunderstand me: this is a necessary condition for a
>> stable performance of KVM VMs, I'm not saying it is sufficient for
>
> I was mostly referring to the existing RT cruft (SCHED_RR/FIFO), that's
> utterly useless for KVM.
>
> As to hosting vcpus with CBS this might maybe make sense, but RT-guests
> are still miles away. Anyway, I'm not quite sure how you would want to
> deal with the guest spinlock issue in CBS, ideally you'd use paravirt
> guests to avoid that whole problem.
>
> Anyway, /me goes do something useful, virt sucks and should be taken out
> back and shot in the head.
>

I dont think we are now still in the track of the patch from Rik, in
which Mike brought the yield_to method into scheduling.

The focus, as I see, is mainly on the effectiveness of the new method,
since it could also be utilized in other environments, though
currently it has nothing to do with the RT cruft but aims at easing
certain lock contention in KVM.

Another issue is that the change in the fair scheduling class,
accompanying the new method, is deserved, for any reason Rik hold.

Lets please return to the patch, and defer the RT.

thanks
Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/