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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 3C991C433E0 for ; Sun, 19 Jul 2020 11:43:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1D8CD207DD for ; Sun, 19 Jul 2020 11:43:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595158996; bh=MNiZtjoNqIAb18wSLVO/N9FDwkqMPyC3q0R6CU/CKTU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=LXn5V6YK8IRhLFOZ8GKApBf6Y1KlFvPMuZ5bDDi86KjEW+chOiH5QgTdajJ/0LQBD ciCqm8CGYcmQZqyDsrFNgJ65xxvT0qOlhNowzl601E4gdUi50ovLz07jaLO8mCc7iY NMxgkUbLtTdqq51Auf/yUPhi+wqTOxu88Y87i/P8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726404AbgGSLnM (ORCPT ); Sun, 19 Jul 2020 07:43:12 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:40152 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725988AbgGSLnL (ORCPT ); Sun, 19 Jul 2020 07:43:11 -0400 Received: by mail-ot1-f67.google.com with SMTP id c25so10125347otf.7; Sun, 19 Jul 2020 04:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qjnIe1TJ50gLn+p9kXcfYDqIZQuO/sCSJOJdD/xzjx0=; b=X6psrmqSkI7JFgKASbjz/rFUxtXiLUPBeOxXS9ZgO736vtLJJrNKGc5m638ITzi7Da 58zxYFcPEdGbtilVWS8Ks4TuB0+WbU8yvTdReNAlWZzgiYJxyyEiDevFaOCBeptYEJq5 ukwYDCbFVqMP/jMgcP1UXebs8nHa2xK74FW5FFwgcGedW32FG734dfcCgf1H2F6w/ABO k55aDjFmQdcunRiRguPH5BYCthZYTSpKNVRXEMXXkbQCPQk5A3vgg2QtjJNgsGQUKiz1 uT4x8v5rbN4gJmeXof4tjHLyqzuJ82VVCQCQkF4jpswYFoM0C+MWpQTlELQTqgD5HeE6 SzSw== X-Gm-Message-State: AOAM531fOjF/fYcSU/T7eXVqpCfgky+vNNl9OfdyF5FHlr6JNkpANS+Z J2zgRTfAXpt/Wg2ilH7O1FjTJSJJL7yez7oImDU= X-Google-Smtp-Source: ABdhPJxrVwgTX8eq+bgwXf+Nz2z5hRxNnikw7DU/gnXd1DP0all26S5yyODzsfs23Hf3e46sRHhV1LyHhMsG15j5jYo= X-Received: by 2002:a05:6830:30ba:: with SMTP id g26mr15288802ots.118.1595158990718; Sun, 19 Jul 2020 04:43:10 -0700 (PDT) MIME-Version: 1.0 References: <3955470.QvD6XneCf3@kreacher> <000f01d65ae8$0c607990$25216cb0$@net> <001201d65c3f$6e2371c0$4a6a5540$@net> In-Reply-To: <001201d65c3f$6e2371c0$4a6a5540$@net> From: "Rafael J. Wysocki" Date: Sun, 19 Jul 2020 13:42:59 +0200 Message-ID: Subject: Re: [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled To: Doug Smythies Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linux Documentation , LKML , Peter Zijlstra , Srinivas Pandruvada , Giovanni Gherdovich , Francisco Jerez , Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug, On Fri, Jul 17, 2020 at 3:37 PM Doug Smythies wrote: > > Hi Rafael, > > Thank you for your reply. > > On 2020.07.16 05:08 Rafael J. Wysocki wrote: > > On Wed, Jul 15, 2020 at 10:39 PM Doug Smythies wrote: > >> On 2020.07.14 11:16 Rafael J. Wysocki wrote: > >> > > >> > From: Rafael J. Wysocki > >> ... > >> > Since the passive mode hasn't worked with HWP at all, and it is not going to > >> > the default for HWP systems anyway, I don't see any drawbacks related to making > >> > this change, so I would consider this as 5.9 material unless there are any > >> > serious objections. > >> > >> Good point. > > Actually, for those users that default to passive mode upon boot, > this would mean they would find themselves using this. > Also, it isn't obvious, from the typical "what driver and what governor" > inquiry. So the change in behavior is that after this patch intel_pstate=passive doesn't imply no_hwp any more. That's a very minor difference though and I'm not aware of any adverse effects it can cause on HWP systems anyway. The "what governor" is straightforward in the passive mode: that's whatever cpufreq governor has been selected. The driver is "intel_cpufreq" which means that the processor is requested to run at a frequency selected by the governor or higher, unless in the turbo range. This works similarly in both the HWP and non-HWP cases, except that in the HWP case it is possible to adjust the EPP (through the additional sysfs knob) and the base frequency is exported (the latter two things can be used to distinguish between the two cases just fine IMO). > >> Some of the tests I do involve labour intensive post processing of data. > >> I want to automate some of that work, and it will take time. > >> We might be into the 5.9-rc series before I have detailed feedback. > >> > >> However, so far: > >> > >> Inverse impulse response test [1]: > >> > >> High level test, i5-9600K, HWP-passive (this patch), ondemand: > >> 3101 tests. 0 failures. (GOOD) > >> > >> From [1], re-stated: > >> > . High level: i5-9600K: 2453 tests, 60 failures, 2.45% fail rate. (HWP-active - powersave) > >> > . Verify acpi-cpufreq/ondemand works fine: i5-9600K: 8975 tests. 0 failures. > >> > >> My version of that cool Alexander named pipe test [2] serialized workflow: > >> > >> HWP-passive (this patch), performance: PASS. > >> > >> From [2], re-stated, and also re-tested. > >> HWP-disabled passive - performance: FAIL. > > > > But I'm not quite sure how this is related to this patch? > > It isn't. The point being that it is different. It is different, but kind of in a positive way IMO. > But yes, that failure is because of our other discussion [3]. OK > > > > This test would still fail without the patch if the kernel was started > > with intel_pstate=passive in the kernel command line, wouldn't it. > > Yes. OK Thanks!