Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4351569pxu; Wed, 9 Dec 2020 15:06:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJxEgvi2udyx6D8U+jBbO1Zcl6VBasBOzK1vBDPry21Gc36K5TCy+qxX62Lu7i0WHswYzy+A X-Received: by 2002:a05:6402:8cc:: with SMTP id d12mr4118731edz.0.1607555192447; Wed, 09 Dec 2020 15:06:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607555192; cv=none; d=google.com; s=arc-20160816; b=C4QNINnzPKuO5sBuBcXOCaj6jmcGyu5cLTAL5Z46JRE5z24XtOo3FmMKigVVr/uDhA 9wapODHJOmyHpbujDeWC77UUI8LJgL4BVXyLR3QRmbKUebnGopah94Q1y/v0HJp6J9Pm lFTI4MsIk8gxxpCUxMcoAVh05zkMN9HIwv73a47Ge71fgwxvrqW47Fke0nZF8Asbirox 3mK1IXfRr7wbd1vSAisVgWgGYj6HaLgUP/x+NdHtcUvvU5bzYwJWietgdBvkNeELOucb wqhJDIuKz3bTh60TIdIEZh6alKd+W7EI3j5jZJJA4KKJceBZh7suLqpZD4Ket6VjlzGM SYYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version; bh=MpAKFQWeV6Ko5JiG2wn5a9RrH94qIFpBwUnb1GB2srg=; b=RJCiLy3UHKr4EvxvMaifGef9x/3WYolbb1fIrOE9tJ70WPQ4KZL2hYg6IUjieKtSV1 xj5kQUg8KRNEBUVmiDRFjb2Yzk0VoAB3b31QyvZmouPIjRjubzXz4as9beyck5E0k/7z eHeqyzwK6Wx203Fzy+2UcUUdJ+FL9WWiPuXZ1rLdVgKoGu3VyHW6F93zxlUnskthjcfk RLk/Y6vBTfhLKyys/T8YbrpQXWpGuCIcUohWzKaRkbf428kf74pUUBsv0phi0legCSNY DwNx01w9J2cW0MX2NJ2EyfenARDT6ok6cUqlKgNF2mpBKX/44LGd8yIVxIWgcoJSNYLp D6Kw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id no7si1481055ejb.586.2020.12.09.15.06.04; Wed, 09 Dec 2020 15:06:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728509AbgLIJoH (ORCPT + 99 others); Wed, 9 Dec 2020 04:44:07 -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...