From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 046F2C432BE for ; Wed, 28 Jul 2021 10:34:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DDCAC60FC0 for ; Wed, 28 Jul 2021 10:34:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235619AbhG1Kea (ORCPT ); Wed, 28 Jul 2021 06:34:30 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54619 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231238AbhG1Ke3 (ORCPT ); Wed, 28 Jul 2021 06:34:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627468468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uQGUnjcG8DsiVM58cgajvTX/4fKYZesHKMKhLyJTwIY=; b=cnGRZ4m3Fg1wG0Rl1bbeBpo6vaJANaO8tdNdgevqzFRNQWdUZhMin6uLjx/xSKxBMQXxjX sfCu9UN85sTS1nnebA+IRCWX3dfRelq3VuUDxvbX/kbrotjZic+3RHustskWAcwFAFQbxI kKb+ZvM3F02hyUOlGP+o7jV16+KMhT0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-521-y6PNLSXhNFyM1DhAHpRRxg-1; Wed, 28 Jul 2021 06:34:26 -0400 X-MC-Unique: y6PNLSXhNFyM1DhAHpRRxg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A743CC73A0; Wed, 28 Jul 2021 10:34:23 +0000 (UTC) Received: from fuller.cnet (ovpn-112-3.gru2.redhat.com [10.97.112.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D0A2B60C05; Wed, 28 Jul 2021 10:34:10 +0000 (UTC) Received: by fuller.cnet (Postfix, from userid 1000) id 961D1416F5D2; Wed, 28 Jul 2021 07:32:53 -0300 (-03) Date: Wed, 28 Jul 2021 07:32:53 -0300 From: Marcelo Tosatti To: Peter Zijlstra Cc: Suleiman Souhlal , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , ssouhlal@freebsd.org, joelaf@google.com, senozhatsky@chromium.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Nitesh Narayan Lal , Nicolas Saenz Julienne Subject: Re: [RFC PATCH 0/2] KVM: Support Heterogeneous RT VCPU Configurations. Message-ID: <20210728103253.GB7633@fuller.cnet> References: <20210728073700.120449-1-suleiman@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 28, 2021 at 10:10:31AM +0200, Peter Zijlstra wrote: > On Wed, Jul 28, 2021 at 04:36:58PM +0900, Suleiman Souhlal wrote: > > Hello, > > > > This series attempts to solve some issues that arise from > > having some VCPUs be real-time while others aren't. > > > > We are trying to play media inside a VM on a desktop environment > > (Chromebooks), which requires us to have some tasks in the guest > > be serviced at real-time priority on the host so that the media > > can be played smoothly. > > > > To achieve this, we give a VCPU real-time priority on the host > > and use isolcpus= to ensure that only designated tasks are allowed > > to run on the RT VCPU. > > WTH do you need isolcpus for that? What's wrong with cpusets? > > > In order to avoid priority inversions (for example when the RT > > VCPU preempts a non-RT that's holding a lock that it wants to > > acquire), we dedicate a host core to the RT vcpu: Only the RT > > VCPU is allowed to run on that CPU, while all the other non-RT > > cores run on all the other host CPUs. > > > > This approach works on machines that have a large enough number > > of CPUs where it's possible to dedicate a whole CPU for this, > > but we also have machines that only have 2 CPUs and doing this > > on those is too costly. > > > > This patch series makes it possible to have a RT VCPU without > > having to dedicate a whole host core for it. > > It does this by making it so that non-RT VCPUs can't be > > preempted if they are in a critical section, which we > > approximate as having interrupts disabled or non-zero > > preempt_count. Once the VCPU is found to not be in a critical > > section anymore, it will give up the CPU. > > There measures to ensure that preemption isn't delayed too > > many times. > > > > (I realize that the hooks in the scheduler aren't very > > tasteful, but I couldn't figure out a better way. > > SVM support will be added when sending the patch for > > inclusion.) > > > > Feedback or alternatives are appreciated. > > This is disguisting and completely wrecks the host scheduling. You're > placing guest over host, that's fundamentally wrong. > > NAK! > > If you want co-ordinated RT scheduling, look at paravirtualized deadline > scheduling. Peter, not sure what exactly are you thinking of? (to solve this particular problem with pv deadline scheduling). Shouldnt it be possible to, through paravirt locks, boost the priority of the non-RT vCPU (when locking fails in the -RT vCPU) ?