Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2288455imm; Wed, 16 May 2018 10:33:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpLXVP3ZPp1Jk6PcypVCa0iHfZYGrUs0U8Mz1il7KmwO90TNKmcRE+XR/hcJU4DoK2sK3cX X-Received: by 2002:a62:a044:: with SMTP id r65-v6mr1800917pfe.235.1526491991030; Wed, 16 May 2018 10:33:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526491990; cv=none; d=google.com; s=arc-20160816; b=E1yQW3JoHX7dBYOhSnHlLbZmgNAcbsFzCWa5u+8ewNxD0kgnZlbM+7as/u+hVEOWAp J0OeLDpNd2plPUextmuclsjJhcvo+xsWKuA362Sb0Zlo/lttCO5wBAYjUIeyKNrroYs2 640uTO5Nn/lswHys5RuhY8nm2Rz/snmtaadSFK/N9Hhyco3L0wHGiaxRxHJzgm/hrHff +dnM4YClW0ZIFeA3MhBEZu41S+9wSVR7XcxniCKlLF28dicBngRjOBwta2A9Zk/sqoT1 KeG05oBV14akgrGAKwMyb09WWLlXHBGCiIaS4/1zUuimpp4w/BuyEgp2Z3JSBn3TVrLU ofFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=ReYlGcG9IX1A4r978iqc85MWuQ6q6D9h0ScY3kKEuc4=; b=r9jkQRCArmQTt6RYsmOqV0q+K6PCaRT66Fy9GY4BVxaFX49ba8Lfcnhob29hKH1d7O XD7bzEr8zuLAr502tKqST/RahJ6Qq4vhNSehIxNaOJWXJwtPHfdVuH4lpU4Mr6ciyvfR CDqF0XePo0m7hkXauWVLAToGVc/DJQP6BMHUEHjyahIoGSmgPCh7Mx8RpFskHySdlY5N uwP73UBb3A4Qnpf3esqc9voXbBw/hFGvTGasAf9Krpe9zGPNVP6+Hf1hCYTdMH534rmw Obwma8+u3Q1qUtAdRAWHPzhMRIS6zgAmrHclrwNCvafdJWFC9KyuK97RW0xtqP3hPnEv qIdw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d18-v6si3047626plr.265.2018.05.16.10.32.56; Wed, 16 May 2018 10:33:10 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751664AbeEPRcl (ORCPT + 99 others); Wed, 16 May 2018 13:32:41 -0400 Received: from mga03.intel.com ([134.134.136.65]:56911 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751430AbeEPRci (ORCPT ); Wed, 16 May 2018 13:32:38 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2018 10:32:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,406,1520924400"; d="scan'208";a="41476023" Received: from spandruv-desk.jf.intel.com ([10.54.75.31]) by orsmga007.jf.intel.com with ESMTP; 16 May 2018 10:32:38 -0700 Message-ID: <1526491957.61700.53.camel@linux.intel.com> Subject: Re: [RFC/RFT] [PATCH 02/10] cpufreq: intel_pstate: Conditional frequency invariant accounting From: Srinivas Pandruvada To: "Rafael J. Wysocki" , Peter Zijlstra Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Len Brown , "Rafael J. Wysocki" , Mel Gorman , the arch/x86 maintainers , Linux PM , Viresh Kumar , Juri Lelli , Linux Kernel Mailing List Date: Wed, 16 May 2018 10:32:37 -0700 In-Reply-To: References: <20180516044911.28797-1-srinivas.pandruvada@linux.intel.com> <20180516044911.28797-3-srinivas.pandruvada@linux.intel.com> <20180516071640.GU12217@hirez.programming.kicks-ass.net> <20180516072929.GN12235@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-05-16 at 11:07 +0200, Rafael J. Wysocki wrote: > On Wed, May 16, 2018 at 9:29 AM, Peter Zijlstra > wrote: > > On Wed, May 16, 2018 at 09:16:40AM +0200, Peter Zijlstra wrote: > > > On Tue, May 15, 2018 at 09:49:03PM -0700, Srinivas Pandruvada > > > wrote: > > > > intel_pstate has two operating modes: active and passive. In > > > > "active" > > > > mode, the in-built scaling governor is used and in "passive" > > > > mode, > > > > the driver can be used with any governor like "schedutil". In > > > > "active" > > > > mode the utilization values from schedutil is not used and > > > > there is > > > > a requirement from high performance computing use cases, not to > > > > read > > > > any APERF/MPERF MSRs. In this case no need to use CPU cycles > > > > for > > > > frequency invariant accounting by reading APERF/MPERF MSRs. > > > > With this change frequency invariant account is only enabled in > > > > "passive" mode. > > > > > > WTH is active/passive? Is passive when we select performance > > > governor? > > > > Bah, I cannot read it seems. active is when we use the intel_pstate > > governor and passive is when we use schedutil and only use > > intel_pstate > > as a driver. > > > > > Also; you have to explain why using APERF/MPERF is bad in that > > > case. Why > > > do they care if we read those MSRs during the tick? > > > > That still stands.. this needs to be properly explained. > > I guess this is from the intel_pstate perspective only. > > The active mode is only used with HWP, so intel_pstate doesn't look > at > the utilization (in any form) in the passive mode today. > > Still, there are other reasons for PELT to be scale-invariant, so ... Not sure about the use case in active mode other than dynamic HWP boost later in this series. If any, I can remove this patch.