From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62360180A6A; Wed, 17 Jul 2024 14:53:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721227984; cv=none; b=MV9yNNkfBWIeq86+/72TSMd6DUfaIxMMHJLnjkk6mqsOfdQuYns852TU3wMK4dBsoW+L8YKd6FMt0iV0wHz2RA9waL6Z1RTwGalqRgRFkH2c1ueb7invl3sCjV3eXJnixiss2X3lOdCuj29IoDEwPxaQjdiRAteql0G02ZRHG9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721227984; c=relaxed/simple; bh=BQu8Xb+iJ8oHoZnOrFTXzZJSBfjBKhTJEwYVf9DXSxY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pYYWbaIuT14fSfIT/lUk5GQNjObrkDKFdtq/8YEGMVwFQfOu1zq66Ixk2qNF7AUDg5vo4hpI4X892w3WlMZe1Na63LSkhoZbGvdtlTl37flP3IXzyCfQEJAVKqnG/Jovn9z7fKYcWGYIVmWOB6gZBxX7mpUK5c713SaEn3ac6Ek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1570BC2BD10; Wed, 17 Jul 2024 14:52:37 +0000 (UTC) Date: Wed, 17 Jul 2024 10:52:33 -0400 From: Steven Rostedt To: Sean Christopherson Cc: Joel Fernandes , Mathieu Desnoyers , Vineeth Remanan Pillai , Ben Segall , Borislav Petkov , Daniel Bristot de Oliveira , Dave Hansen , Dietmar Eggemann , "H . Peter Anvin" , Ingo Molnar , Juri Lelli , Mel Gorman , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Valentin Schneider , Vincent Guittot , Vitaly Kuznetsov , Wanpeng Li , Suleiman Souhlal , Masami Hiramatsu , himadrics@inria.fr, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, graf@amazon.com, drjunior.org@gmail.com Subject: Re: [RFC PATCH v2 0/5] Paravirt Scheduling (Dynamic vcpu priority management) Message-ID: <20240717105233.07b4ec00@rorschach.local.home> In-Reply-To: <20240717103647.735563af@rorschach.local.home> References: <66912820.050a0220.15d64.10f5@mx.google.com> <19ecf8c8-d5ac-4cfb-a650-cf072ced81ce@efficios.com> <20240712122408.3f434cc5@rorschach.local.home> <20240712131232.6d77947b@rorschach.local.home> <20240717103647.735563af@rorschach.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 17 Jul 2024 10:36:47 -0400 Steven Rostedt wrote: > The problem with that is the only use case for such a feature is for > vCPUS. There's no use case for a single thread to up and down its > priority. I work a lot in RT applications (well, not as much anymore, > but my career was heavy into it). And I can't see any use case where a > single thread would bounce its priority around. In fact, if I did see > that, I would complain that it was a poorly designed system. > > Now for a guest kernel, that's very different. It has to handle things > like priority inheritance and such, where bouncing a threads (or its > own vCPU thread) priority most definitely makes sense. > > So you are requesting that we add a bad user space interface to allow > lazy priority management from a thread so that we can use it in the > proper use case of a vCPU? Now I stated the above thinking you wanted to add a generic interface for all user space. But perhaps there is a way to get this to be done by the scheduler itself. But its use case is still only for VMs. We could possibly add a new sched class that has a dynamic priority. That is, it can switch between other sched classes. A vCPU thread could be assigned to this class from inside the kernel (via a virtio device) where this is not exposed to user space at all. Then the virtio device would control the mapping of a page between the vCPU thread and the host kernel. When this task gets scheduled, it can call into the code that handles the dynamic priority. This will require buy-in from the scheduler folks. This could also handle the case of a vCPU being woken up by an interrupt, as the hooks could be there on the wakeup side as well. Thoughts? -- Steve