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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D0BA8C4361B for ; Wed, 9 Dec 2020 09:43:25 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 2861923B7D for ; Wed, 9 Dec 2020 09:43:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2861923B7D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 69CA64B28B; Wed, 9 Dec 2020 04:43:24 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR2hdVmeqz4a; Wed, 9 Dec 2020 04:43:22 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8B3734B2C2; Wed, 9 Dec 2020 04:43:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 765C04B28B for ; Wed, 9 Dec 2020 04:43:21 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdJhX1A3-5pt for ; Wed, 9 Dec 2020 04:43:20 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 263B74B13A for ; Wed, 9 Dec 2020 04:43:20 -0500 (EST) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C4756233FA; Wed, 9 Dec 2020 09:43:18 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kmw0C-00HKn3-JQ; Wed, 09 Dec 2020 09:43:16 +0000 MIME-Version: 1.0 Date: Wed, 09 Dec 2020 09:43:16 +0000 From: Marc Zyngier To: Joel Fernandes Subject: Re: [RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted In-Reply-To: References: <20200721041742.197354-1-sergey.senozhatsky@gmail.com> <20200817020310.GA1210848@jagdpanzerIV.localdomain> <20200911085841.GB562@jagdpanzerIV.localdomain> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: joelaf@google.com, sergey.senozhatsky@gmail.com, yezengruan@huawei.com, will@kernel.org, linux-kernel@vger.kernel.org, suleiman@google.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, wanghaibin.wang@huawei.com, qperret@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: LKML , Sergey Senozhatsky , Suleiman Souhlal , Will Deacon , kvmarm@lists.cs.columbia.edu, "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi all, On 2020-12-08 20:02, Joel Fernandes wrote: > On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky > wrote: >> >> My apologies for the slow reply. >> >> On (20/08/17 13:25), Marc Zyngier wrote: >> > >> > It really isn't the same thing at all. You are exposing PV spinlocks, >> > while Sergey exposes preemption to vcpus. >> > >> >> Correct, we see vcpu preemption as a "fundamental" feature, with >> consequences that affect scheduling, which is a core feature :) >> >> Marc, is there anything in particular that you dislike about this RFC >> patch set? Joel has some ideas, which we may discuss offline if that >> works for you. > > Hi Marc, Sergey, Just checking what is the latest on this series? I was planning to give it a go, but obviously got sidetracked. :-( > > About the idea me and Sergey discussed, at a high level we discussed > being able to share information similar to "Is the vCPU preempted?" > using a more arch-independent infrastructure. I do not believe this > needs to be arch-specific. Maybe the speciifc mechanism about how to > share a page of information needs to be arch-specific, but the actual > information shared need not be. We already have some information sharing in the form of steal time accounting, and I believe this "vcpu preempted" falls in the same bucket. It looks like we could implement the feature as an extension of the steal-time accounting, as the two concepts are linked (one describes the accumulation of non-running time, the other is instantaneous). > This could open the door to sharing > more such information in an arch-independent way (for example, if the > scheduler needs to know other information such as the capacity of the > CPU that the vCPU is on). Quentin and I have discussed potential ways of improving guest scheduling on terminally broken systems (otherwise known as big-little), in the form of a capacity request from the guest to the host. I'm not really keen on the host exposing its own capacity, as that doesn't tell the host what the guest actually needs. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 BFB60C433FE for ; Wed, 9 Dec 2020 09:44:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4F95F233FD for ; Wed, 9 Dec 2020 09:44:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F95F233FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=w/+a2Z8KlcBYzhZC4fDindQU+1nN7eh16e1mZAVO7zY=; b=ZLyI0IEFtsbJsSL14fZXtxuTH sKbau+h8RKo76kvt/S96cQVUXJR8VOc0XRugIurbmO2qiAg/NNJ8ZvoMR+GuOhjaxW8ERuQcpL8AL f3Aa4c8pAzUg6O7mN+jYX/6aJL82NhJbFXJk0Pl/n50mfB5BC6xQJqMuEgAKFDYEHX3n/8Td5liLu L6P6vAlJMCQe4S9hYcTVHhB9AL7/piIcpGFXQ2zdxyzEib1IxXUA4nTi4UxfhecBT7yLi8lBUv7SJ SrfeEe2riR3LhHNF8obcJ6SDcbaIjbIpQmqzI2ZdNKVSRfAwLCZ6egAAkMA6KgpkL7SISSax25yY8 S4LhSctoA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmw0J-000532-2e; Wed, 09 Dec 2020 09:43:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmw0F-000525-Sl for linux-arm-kernel@lists.infradead.org; Wed, 09 Dec 2020 09:43:21 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C4756233FA; Wed, 9 Dec 2020 09:43:18 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kmw0C-00HKn3-JQ; Wed, 09 Dec 2020 09:43:16 +0000 MIME-Version: 1.0 Date: Wed, 09 Dec 2020 09:43:16 +0000 From: Marc Zyngier To: Joel Fernandes Subject: Re: [RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted In-Reply-To: References: <20200721041742.197354-1-sergey.senozhatsky@gmail.com> <20200817020310.GA1210848@jagdpanzerIV.localdomain> <20200911085841.GB562@jagdpanzerIV.localdomain> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: joelaf@google.com, sergey.senozhatsky@gmail.com, yezengruan@huawei.com, will@kernel.org, linux-kernel@vger.kernel.org, suleiman@google.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, wanghaibin.wang@huawei.com, qperret@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201209_044320_095022_ADA8AEDE X-CRM114-Status: GOOD ( 22.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: yezengruan , Quentin Perret , LKML , Sergey Senozhatsky , "Wanghaibin \(D\)" , Suleiman Souhlal , Will Deacon , kvmarm@lists.cs.columbia.edu, "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, On 2020-12-08 20:02, Joel Fernandes wrote: > On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky > wrote: >> >> My apologies for the slow reply. >> >> On (20/08/17 13:25), Marc Zyngier wrote: >> > >> > It really isn't the same thing at all. You are exposing PV spinlocks, >> > while Sergey exposes preemption to vcpus. >> > >> >> Correct, we see vcpu preemption as a "fundamental" feature, with >> consequences that affect scheduling, which is a core feature :) >> >> Marc, is there anything in particular that you dislike about this RFC >> patch set? Joel has some ideas, which we may discuss offline if that >> works for you. > > Hi Marc, Sergey, Just checking what is the latest on this series? I was planning to give it a go, but obviously got sidetracked. :-( > > About the idea me and Sergey discussed, at a high level we discussed > being able to share information similar to "Is the vCPU preempted?" > using a more arch-independent infrastructure. I do not believe this > needs to be arch-specific. Maybe the speciifc mechanism about how to > share a page of information needs to be arch-specific, but the actual > information shared need not be. We already have some information sharing in the form of steal time accounting, and I believe this "vcpu preempted" falls in the same bucket. It looks like we could implement the feature as an extension of the steal-time accounting, as the two concepts are linked (one describes the accumulation of non-running time, the other is instantaneous). > This could open the door to sharing > more such information in an arch-independent way (for example, if the > scheduler needs to know other information such as the capacity of the > CPU that the vCPU is on). Quentin and I have discussed potential ways of improving guest scheduling on terminally broken systems (otherwise known as big-little), in the form of a capacity request from the guest to the host. I'm not really keen on the host exposing its own capacity, as that doesn't tell the host what the guest actually needs. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 1BA58C4361B for ; Wed, 9 Dec 2020 09:44:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C7A1E233FD for ; Wed, 9 Dec 2020 09:44:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729193AbgLIJoN (ORCPT ); Wed, 9 Dec 2020 04:44:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:55030 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729061AbgLIJn7 (ORCPT ); Wed, 9 Dec 2020 04:43:59 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C4756233FA; Wed, 9 Dec 2020 09:43:18 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kmw0C-00HKn3-JQ; Wed, 09 Dec 2020 09:43:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Dec 2020 09:43:16 +0000 From: Marc Zyngier To: Joel Fernandes Cc: Sergey Senozhatsky , yezengruan , Will Deacon , LKML , Suleiman Souhlal , kvmarm@lists.cs.columbia.edu, "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , "Wanghaibin (D)" , Quentin Perret Subject: Re: [RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted In-Reply-To: References: <20200721041742.197354-1-sergey.senozhatsky@gmail.com> <20200817020310.GA1210848@jagdpanzerIV.localdomain> <20200911085841.GB562@jagdpanzerIV.localdomain> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: joelaf@google.com, sergey.senozhatsky@gmail.com, yezengruan@huawei.com, will@kernel.org, linux-kernel@vger.kernel.org, suleiman@google.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, wanghaibin.wang@huawei.com, qperret@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On 2020-12-08 20:02, Joel Fernandes wrote: > On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky > wrote: >> >> My apologies for the slow reply. >> >> On (20/08/17 13:25), Marc Zyngier wrote: >> > >> > It really isn't the same thing at all. You are exposing PV spinlocks, >> > while Sergey exposes preemption to vcpus. >> > >> >> Correct, we see vcpu preemption as a "fundamental" feature, with >> consequences that affect scheduling, which is a core feature :) >> >> Marc, is there anything in particular that you dislike about this RFC >> patch set? Joel has some ideas, which we may discuss offline if that >> works for you. > > Hi Marc, Sergey, Just checking what is the latest on this series? I was planning to give it a go, but obviously got sidetracked. :-( > > About the idea me and Sergey discussed, at a high level we discussed > being able to share information similar to "Is the vCPU preempted?" > using a more arch-independent infrastructure. I do not believe this > needs to be arch-specific. Maybe the speciifc mechanism about how to > share a page of information needs to be arch-specific, but the actual > information shared need not be. We already have some information sharing in the form of steal time accounting, and I believe this "vcpu preempted" falls in the same bucket. It looks like we could implement the feature as an extension of the steal-time accounting, as the two concepts are linked (one describes the accumulation of non-running time, the other is instantaneous). > This could open the door to sharing > more such information in an arch-independent way (for example, if the > scheduler needs to know other information such as the capacity of the > CPU that the vCPU is on). Quentin and I have discussed potential ways of improving guest scheduling on terminally broken systems (otherwise known as big-little), in the form of a capacity request from the guest to the host. I'm not really keen on the host exposing its own capacity, as that doesn't tell the host what the guest actually needs. Thanks, M. -- Jazz is not dead. It just smells funny...