Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1173714ybd; Wed, 26 Jun 2019 12:33:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQ+HVtaYZY6GBXq7pGTqnM1ePrxCqhize0WkPSlXKEWKQqhbnrt25Hwnzd7aaqI12gej4G X-Received: by 2002:a17:90a:7f02:: with SMTP id k2mr380027pjl.78.1561577605577; Wed, 26 Jun 2019 12:33:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561577605; cv=none; d=google.com; s=arc-20160816; b=dgDBirjvO7BivcKBfkHoC6LlB3PgsIViYwT3Umq5ZdNItbGkb2c7B/acGYybRag9PS zsnoEuGHAD405bdkox595bK5cjX6rELOrw7HndE74Ylhz0J4DV4nRTbjGhM8FTfI0atn 01/QUAH+MjeoJ+U5utbZg6XsbEfhYjoIqLVJgVdZQpwxfcUaghG4E9h+uEV6ie+r7zfc upEdcVGsmW1r9N1IAaG7sXrkhJzzqcc5iPOFDMfulyMhgJ6Te2y9rPmU9AO5cJvoOTwj /n6cT7g1VTpTghVFuzbthiUrt+WSSkRo4DvYw/7uzEP4U5awphl4TYr1pgo62ttQhR80 sZPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=QAsOqLtmxVhZQbyStvyUZFWrPqAYUQg5UpykH5olvz0=; b=U1udPon/uRb1P7Zm7bqJAOUrDGvG8EJ7JFA7UR0JWA19/vUU9Gsh/SCqGxwc7i+oFU jM3JcBmnSTXUWQm335FboF2G0psTN17pNXNLPn0fYtUyxPym+roMz95noJnS53tJVVRN FI0fVGM1d1ZmNfztOdB3z7HMqq8zBh7YddCZEeE8PuVBZED2vLSd1/xpMA7lI6CzYgcS I78SotdYjuIMoxUaMWhLtq1j7AEEweE17IBENiI2WkILQwgavz1W7qgJjNkt6F9fzudn LoS9/UN3JxbGD9p/WCU4FxvbF5Lrgba/b1Mb1CuvmdLwRSGClqZQJkvaZvL6TmnhqrkH 7g+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bc7si4392plb.55.2019.06.26.12.33.09; Wed, 26 Jun 2019 12:33:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726379AbfFZTcm (ORCPT + 99 others); Wed, 26 Jun 2019 15:32:42 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:50205 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbfFZTcl (ORCPT ); Wed, 26 Jun 2019 15:32:41 -0400 Received: from p5b06daab.dip0.t-ipconnect.de ([91.6.218.171] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hgDem-0004av-8B; Wed, 26 Jun 2019 21:32:36 +0200 Date: Wed, 26 Jun 2019 21:32:35 +0200 (CEST) From: Thomas Gleixner To: "Raslan, KarimAllah" cc: "peterz@infradead.org" , "boris.ostrovsky@oracle.com" , "kvm@vger.kernel.org" , "kernellwp@gmail.com" , "joao.m.martins@oracle.com" , "linux-kernel@vger.kernel.org" , "konrad.wilk@oracle.com" , "mtosatti@redhat.com" , "pbonzini@redhat.com" , "ankur.a.arora@oracle.com" , "rkrcmar@redhat.com" Subject: Re: cputime takes cstate into consideration In-Reply-To: <1561577254.25880.15.camel@amazon.de> Message-ID: References: <20190626145413.GE6753@char.us.oracle.com> <20190626161608.GM3419@hirez.programming.kicks-ass.net> <20190626183016.GA16439@char.us.oracle.com> <1561575336.25880.7.camel@amazon.de> <20190626192100.GP3419@hirez.programming.kicks-ass.net> <1561577254.25880.15.camel@amazon.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-596458942-1561577556=:32342" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-596458942-1561577556=:32342 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Wed, 26 Jun 2019, Raslan, KarimAllah wrote: > On Wed, 2019-06-26 at 21:21 +0200, Peter Zijlstra wrote: > > On Wed, Jun 26, 2019 at 06:55:36PM +0000, Raslan, KarimAllah wrote: > > > > > > > > If the host is completely in no_full_hz mode and the pCPU is dedicated to a  > > > single vCPU/task (and the guest is 100% CPU bound and never exits), you would  > > > still be ticking in the host once every second for housekeeping, right? Would  > > > not updating the mwait-time once a second be enough here? > > > > People are trying very hard to get rid of that remnant tick. Lets not > > add dependencies to it. > > > > IMO this is a really stupid issue, 100% time is correct if the guest > > does idle in pinned vcpu mode. > > One use case for proper accounting (obviously for a slightly relaxed definition  > or *proper*) is *external* monitoring of CPU utilization for scaling group > (i.e. more VMs will be launched when you reach a certain CPU utilization). > These external monitoring tools needs to account CPU utilization properly. Then you need a trusted cooperative guest and that can give you the information. If it doesn't, then either do not give him MWAIT or the scheme does not work. If you can afford to waste performance counters for that, you can do that from user space. There are lots of options, but the kernel won't chose one because it's guaranteed to be the wrong choice for most scenarios. Thanks, tglx --8323329-596458942-1561577556=:32342--