Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1543106rwi; Thu, 13 Oct 2022 15:35:22 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7zKmwYQJotKDzBwcmKRu/sX+xGZTeYXerWJYLXBMgfM8Djk9b1oRG8XpGA1JOg/dqx3bac X-Received: by 2002:a05:6402:c4d:b0:457:99ec:1837 with SMTP id cs13-20020a0564020c4d00b0045799ec1837mr1663952edb.86.1665700522704; Thu, 13 Oct 2022 15:35:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665700522; cv=none; d=google.com; s=arc-20160816; b=XzIU2H+q1u6e/6P43Y9KaLMJR8IVc3dI51492nM6iAJ0RVtQ/yju6kJX6oDKtzV/jm UEq9RNNFhrwQehN8egvGyQ7yNuewRc020KQHsH+LJeC3onKYwIi1buNao3kUIsbhjkmD szcrxEvObs3gtYm86rkwqSvnnas9bL9jNDKZq+o7Verl4eKe94fUWiEMkdhwM80E/Iwj nhw4LIVJsswXRExD929F4w3uAh56MHQmvbPKdpZ66uXq6TukgKHQNLHDJ15BzD+rZ/VC 56ukOR8kNXIZx7AmvZU1CxAECmT+a4zmTBu1esrXVUU+T92s1DNCeieN4LwYZbUaH4Ir L6Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=xLlp+L6UoYHOMNwsqCOlw+S3zS7vqmcy26ijo646RY8=; b=xpeEDx41+qfndve53Jp7vdlJgJrVIxFo+5SRPrSKnWt8FB8Ae4FW8hY8kq7bIjvVRB tyQKcnlpuBTCzxId/dXlCVW3rn0QGVUb+PDBT4CuMVGJ1sTiixuu/TkRed3k9rCKqLda vOyddbrSpPP82XDoZbRbLmAZg+uA8ZOIciJndyIVhwEd37A2A1/0WqB8q8XZKRPM+8D/ oY1R0vKLdS1g0e/GBbvijt7/kBxVTlghVFXCrYue/HUFom93m0M1gtCAvFDQGdSLbdaY fvnoOkMkFmd+bMa44ah5xFAEd7w8Xi/3oFa4kfc+xNPVvA3/bL4oR+Ervn3N/+tYM9wu hrCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@telus.net header.s=google header.b=O8AEMcxi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telus.net Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l15-20020a170906794f00b0078da3cd3073si871196ejo.628.2022.10.13.15.34.56; Thu, 13 Oct 2022 15:35:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@telus.net header.s=google header.b=O8AEMcxi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telus.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229810AbiJMWNE (ORCPT + 99 others); Thu, 13 Oct 2022 18:13:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbiJMWNB (ORCPT ); Thu, 13 Oct 2022 18:13:01 -0400 Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 023FE18BE28 for ; Thu, 13 Oct 2022 15:13:00 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id a6so1468133vkm.9 for ; Thu, 13 Oct 2022 15:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xLlp+L6UoYHOMNwsqCOlw+S3zS7vqmcy26ijo646RY8=; b=O8AEMcxiWJI/qRNaoqxoTmxniQ9mIt/D1O8aw6Xrsja8xvG3vcNZxYIRhpQbVri1F8 ZqvYt/RpHfeFWiK+32uburTgHLokD29VaTTMabo52h7yqi5/0HoMV3eSvhdA8Q17ndwD rA1hRVvKw6wdjCKa5eMKFnfvv8ssXfsRhQvI/t/aHeU71MDMuGcSQQJZCzHv1LQxncDw 6qZUQUc8unyuy1LuDR8aVyztxamFjvjkT7Jg1MECrfLYRPGO9Gwib6XeOe3AYJjzqrHN 2ZhhLISav5qVUvTLWp+c0uPxHcsWW2H1fC5dQtGLpN7YAD+6ZThAmPStIjQ6DaUndtHg ZQww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xLlp+L6UoYHOMNwsqCOlw+S3zS7vqmcy26ijo646RY8=; b=3DazfaRmy/OJQl5OjZSfCts5j6uOdkVCe0UMsuEkOBBJzCyrQy7pGDxqqOOvLucuCS ooluGZSLtxb6Rh/APosxG3cW42Mx0HKwEwT2TEzXOJyF48XP5ldeb8nwVGWPkujx3C2z cG0lPZbV0QU3Ddam7u+iA1kQ58dMVeACcaqZ7kbwrLgix6ojt9UKRGfx730WsNp0uSch nMfNFFv9PGKZc8/JuiEbjZR45Nl2DHG7dFVq9Md9wx5BXrmk7wT8QfNYMFA+XsZp691d R6UlK7mQwSH0GxMrsvtWe69QdUZR2cDNLYUVsx6ppZFFB5u/OYS7nJAzGyrDEZieNwnE OQgA== X-Gm-Message-State: ACrzQf2O3jiu+nK3sZLyEya061trhZ+3kF3IG/HY7iDpkc4txqHEsGos GwhZIBYqcVMiQH77vdvfTS2kDazzYQ7sdaEO8I1Omg== X-Received: by 2002:a1f:5981:0:b0:3a6:6655:831f with SMTP id n123-20020a1f5981000000b003a66655831fmr1350689vkb.12.1665699179056; Thu, 13 Oct 2022 15:12:59 -0700 (PDT) MIME-Version: 1.0 References: <20221003144914.160547-1-kajetan.puchalski@arm.com> In-Reply-To: From: Doug Smythies Date: Thu, 13 Oct 2022 15:12:53 -0700 Message-ID: Subject: Re: [RFC PATCH v2 0/1] cpuidle: teo: Introduce optional util-awareness To: Kajetan Puchalski Cc: "Rafael J. Wysocki" , daniel.lezcano@linaro.org, lukasz.luba@arm.com, Dietmar.Eggemann@arm.com, yu.chen.surf@gmail.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Doug Smythies Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi All, On Thu, Oct 13, 2022 at 4:12 AM Kajetan Puchalski wrote: > On Wed, Oct 12, 2022 at 08:50:39PM +0200, Rafael J. Wysocki wrote: > > On Mon, Oct 3, 2022 at 4:50 PM Kajetan Puchalski > > wrote: ... > On the Intel & power usage angle you might have seen in the discussion, > Doug sent me some interesting data privately. As far as I can tell the > main issue there is that C0 on Intel doesn't actually do power saving so > moving the state selection down to it is a pretty bad idea because C1 > could be very close in terms of latency and save much more power. > > A potential solution could be altering the v2 to only decrease the state > selection by 1 if it's above 1, ie 2->1 but not 1->0. It's fine for us > because arm systems with 2 states use the early exit path anyway. It'd > just amount to changing this hunk: > > + if (cpu_data->utilized && idx > 0 && !dev->states_usage[idx-1].disable) > + idx--; > > to: > > + if (cpu_data->utilized && idx > 1 && !dev->states_usage[idx-1].disable) > + idx--; > > What would you think about that? Should make it much less intense for > Intel systems. I tested the above, which you sent me as patch version v2-2. By default, my Intel i5-10600K has 4 idle states: $ grep . /sys/devices/system/cpu/cpu7/cpuidle/state*/name /sys/devices/system/cpu/cpu7/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu7/cpuidle/state1/name:C1_ACPI /sys/devices/system/cpu/cpu7/cpuidle/state2/name:C2_ACPI /sys/devices/system/cpu/cpu7/cpuidle/state3/name:C3_ACPI Idle driver governor legend: teo: the normal teo idle governor menu: the normal menu idle governor util or v1: the original patch util-v2 or v2: V2 of the patch util-v2-2 or v2-2: the suggestion further up in this thread. Test 1: Timer based periodic: A load sweep from 0 to 100%, then 100% to 0, first 73 hertz, then 113, 211,347 and finally 401 hertz work/sleep frequency. Single thread. http://smythies.com/~doug/linux/idle/teo-util/consume/idle-1/ Summary, average processor package powers (watts): teo menu v1 v2 v2-2 10.19399 10.74804 22.12791 21.0431 11.27865 5.44% 117.07% 106.43% 10.64% There is no performance measurement for this test, it just has to finish the work packet before the next period starts. Note that overruns do occur as the workload approaches 100%, but I do not record that data, as typically the lower workload percentages are the area of interest. Test 2: Ping-pong test rotating through 6 different cores, with a variable packet of work to do at each stop. This test goes gradually through different idle states and is not timer based. A different 2 core test (which I have not done) is used to better explore the idle state 0 to idle state 1 transition. This test has a performance measurement. The CPU scaling governor was set to performance. HWP was disabled. http://smythies.com/~doug/linux/idle/teo-util/ping-sweep/6-1/loop-times.png http://smythies.com/~doug/linux/idle/teo-util/ping-sweep/6-1/loop-times-detail-a.png http://smythies.com/~doug/linux/idle/teo-util/ping-sweep/6-1/ Summary: Average processor package power (watts): teo v2-2 menu 27.3881 29.98293 28.04096 9.47% 2.38% Execution time for the entire test (minutes): teo v2-2 menu 56 54.667 55.333 -2.38% -1.19% However, notice that in the idle-state 0 and 1 region, V2-2 uses more power and its loop time is longer (less is better), but also in the deeper idle states regions V2-2 uses more power and also runs faster. teo: 36.4 watts and 10.3533 usecs/loop. menu: 36.8 watts and 10.1604 usecs/loop. util-v2-2: 38.8 watts and 11.2358 usecs/loop. and teo: 15.2 watts and 1,777.6 usecs/loop. menu: 15.6 watts and 1767.4 usecs/loop. util-v2-2: 17.4 watts and 1618.7 usecs/loop. ... Doug