Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp531188ybl; Fri, 31 Jan 2020 03:26:40 -0800 (PST) X-Google-Smtp-Source: APXvYqwRh0ipGNJAsymQ7DizWWSDcOJQQdU6upIDyxq6fcmeJdoq5ITodbXvXYVS6VaXkCTuMU5P X-Received: by 2002:aca:3857:: with SMTP id f84mr5687038oia.150.1580470000027; Fri, 31 Jan 2020 03:26:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580470000; cv=none; d=google.com; s=arc-20160816; b=nhH3eF+yXYyGCQGrRzQ7r9l0FeZs7ylbhmaGnUnJxy9/iwNoPjmPwmU1IApwH/ysZk 9/BME3j5BF+Q3rGPymKlJtxqG1BK7TPDZFucpQ6Cr3s60dWxDq6Mnbx9GKHZmyvKYJ7q Z9FaYDfr/ShaLJ0uXxuc+6pkux+x8N8drW+Ihu0DsqMiFoz6yA0WV5kxgCr//VGHbu0t yl7xYoXYKP7ql5G4tMQWjUqfjZK5qSh/IbCqrjpX+Aojam69T6xkJBFs/54NBgg/uV3u 0LVBajFa9fdkw5+PGlkzmRp2PsAowMJn2y8EOPUDjaVzHDBszI+nm6bQBtAseY3v9+p/ KU2g== 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 :user-agent:references:in-reply-to:date:cc:to:reply-to:from:subject :message-id; bh=MPrtwhi1kdCpL6Lnx5cbUzXv6HwY/dw0SoNMT9EE20w=; b=uSV1iOAbWcvKdABXpV4o5FQ7iHw9P2nCGxq3x7AIWiWkymAgKxt2OvelToajad+/3j srSQR6+2vUe9R8r63tlcHDL/w9ckGBK2cBfmgjpqkBLnBudYqnsSBwl3WSsKfkauusa6 OJy9bovDF1oAKjmXPr62bWw/mbNdkVul1a/D+uYkgdBCv6kW9DTrc98mFCqtb3HYdJv8 nM8+MGb5X3QGrtj+qErOqLtZVr8LhQ8BW0sLKW2oxAmnogj1vERKnbf2SztHY2U9c4Gg 0jJ55vMqDYEXhviKWDRbCuJzYdJXHyMPV2A2VpzGQdFy49z1Nqhfr2OrZq+gHnQgTeqO KNLw== 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 l9si4583520oti.229.2020.01.31.03.26.27; Fri, 31 Jan 2020 03:26:40 -0800 (PST) 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 S1728425AbgAaLY3 (ORCPT + 99 others); Fri, 31 Jan 2020 06:24:29 -0500 Received: from mga05.intel.com ([192.55.52.43]:31212 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728268AbgAaLY3 (ORCPT ); Fri, 31 Jan 2020 06:24:29 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2020 03:24:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,385,1574150400"; d="scan'208";a="218585313" Received: from linux.intel.com ([10.54.29.200]) by orsmga007.jf.intel.com with ESMTP; 31 Jan 2020 03:24:28 -0800 Received: from abityuts-desk1.fi.intel.com (abityuts-desk1.fi.intel.com [10.237.68.148]) by linux.intel.com (Postfix) with ESMTP id A121A580277; Fri, 31 Jan 2020 03:24:25 -0800 (PST) Message-ID: <28a92577c83276baf355dc8de272a79dc854025a.camel@linux.intel.com> Subject: Re: [PATCH 2/2] intel_idle: Introduce 'states_off' module parameter From: Artem Bityutskiy Reply-To: artem.bityutskiy@linux.intel.com To: David Laight , "'Rafael J. Wysocki'" , Linux PM Cc: Linux ACPI , LKML , Len Brown , Zhang Rui , David Box , "Rafael J. Wysocki" Date: Fri, 31 Jan 2020 13:24:24 +0200 In-Reply-To: <86fb1cd10e344f76a3e96c4b6c722680@AcuMS.aculab.com> References: <1720216.0Jr2BLnqKp@kreacher> <16995896.bQtfYxEEOs@kreacher> <86fb1cd10e344f76a3e96c4b6c722680@AcuMS.aculab.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) 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 Fri, 2020-01-31 at 11:07 +0000, David Laight wrote: > Unless you know exactly which cpu table is being used the > only constraint a user can request is the latency. Hi David, in all my use-cases I always know what is the CPU I am dealing with and what are the C-states. Simply because in my view they are always CPU- dependent in terms of what they do and how are they named. What you say sounds to me like you would want to disable some C-states without knowing anything (or much) about the CPU you are dealing with and the C-state names. If so, could you please share examples of such use-cases? Thanks! -- Best Regards, Artem Bityutskiy