From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751754AbdIWK4V (ORCPT <rfc822;w@1wt.eu>);
        Sat, 23 Sep 2017 06:56:21 -0400
Received: from mail-wm0-f68.google.com ([74.125.82.68]:32887 "EHLO
        mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750814AbdIWK4T (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 23 Sep 2017 06:56:19 -0400
X-Google-Smtp-Source: AOwi7QDG9jAvK/9NZuwPWnQtfxaAZC036y29w/HktwElRKlRX5lTWfry5l/WJaOJw0EzcyZBgyvKNA==
Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO
 hypercall
To: Peter Zijlstra <peterz@infradead.org>,
        Marcelo Tosatti <mtosatti@redhat.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, mingo@redhat.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>
References: <20170921113835.031375194@redhat.com>
 <20170921114039.466130276@redhat.com>
 <20170921133653.GO26248@char.us.oracle.com>
 <20170921140628.zliqlz7mrlqs5pzz@hirez.programming.kicks-ass.net>
 <20170922011039.GB20133@amt.cnet>
 <20170922100004.ydmaxvgpc2zx7j25@hirez.programming.kicks-ass.net>
 <20170922105609.deln6kylvvpaijg7@hirez.programming.kicks-ass.net>
 <20170922123305.GB29608@amt.cnet>
 <20170922125556.cyzybj6c7jqypbmo@hirez.programming.kicks-ass.net>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <951aaa3f-b20d-6f67-9454-f193f4445fc7@redhat.com>
Date: Sat, 23 Sep 2017 12:56:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170922125556.cyzybj6c7jqypbmo@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 22/09/2017 14:55, Peter Zijlstra wrote:
> You just explained it yourself. If the thread that needs to complete
> what you're waiting on has lower priority, it will _never_ get to run if
> you're busy waiting on it.
> 
> This is _trivial_.
> 
> And even for !RT it can be quite costly, because you can end up having
> to burn your entire slot of CPU time before you run the other task.
> 
> Userspace spinning is _bad_, do not do this.

This is not userspace spinning, it is guest spinning---which has
effectively the same effect but you cannot quite avoid.

But I agree that the solution is properly prioritizing threads that can
interrupt the VCPU, and using PI mutexes.

I'm not a priori opposed to paravirt scheduling primitives, but I am not
at all sure that it's required.

Paolo

> (the one exception where it works is where you have a single thread per
> cpu, because then there's effectively no scheduling).