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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D32CEC433FE for ; Thu, 10 Nov 2022 12:46:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229833AbiKJMqD (ORCPT ); Thu, 10 Nov 2022 07:46:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229843AbiKJMp7 (ORCPT ); Thu, 10 Nov 2022 07:45:59 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D3ED364A25 for ; Thu, 10 Nov 2022 04:45:56 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 43E241FB; Thu, 10 Nov 2022 04:46:02 -0800 (PST) Received: from e126311.manchester.arm.com (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 01CEE3F703; Thu, 10 Nov 2022 04:45:52 -0800 (PST) Date: Thu, 10 Nov 2022 12:45:18 +0000 From: Kajetan Puchalski To: Peter Zijlstra Cc: Jian-Min Liu , Dietmar Eggemann , Ingo Molnar , Vincent Guittot , Morten Rasmussen , Vincent Donnefort , Quentin Perret , Patrick Bellasi , Abhijeet Dharmapurikar , Qais Yousef , linux-kernel@vger.kernel.org, Jonathan JMChen Subject: Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime Message-ID: References: <20220829055450.1703092-1-dietmar.eggemann@arm.com> <0f82011994be68502fd9833e499749866539c3df.camel@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > Would something terrible like the below help some? > > If not, I suppose it could be modified to take the current state as > history. But basically it runs a faster pelt sum along side the regular > signal just for ramping up the frequency. As Dietmar mentioned in the other email, there seems to be an issue with how the patch computes 'runtime'. Nevertheless I tested it just to see what would happen so here are the results if you're interested. Here's a comparison of Jankbench results on a normal system vs pelt_4 vs performance cpufreq governor vs your pelt_rampup patch. Max frame duration (ms) +-----------------------+-----------+------------+ | kernel | iteration | value | +-----------------------+-----------+------------+ | menu | 10 | 142.973401 | | menu_pelt_4 | 10 | 85.271279 | | menu_pelt_rampup | 10 | 61.494636 | | menu_performance | 10 | 40.930829 | +-----------------------+-----------+------------+ Power usage [mW] +--------------+-----------------------+-------+-----------+ | chan_name | kernel | value | perc_diff | +--------------+-----------------------+-------+-----------+ | total_power | menu | 144.6 | 0.0% | | total_power | menu_pelt_4 | 158.5 | 9.63% | | total_power | menu_pelt_rampup | 272.1 | 88.23% | | total_power | menu_performance | 485.6 | 235.9% | +--------------+-----------------------+-------+-----------+ Mean frame duration (ms) +---------------+-----------------------+-------+-----------+ | variable | kernel | value | perc_diff | +---------------+-----------------------+-------+-----------+ | mean_duration | menu | 13.9 | 0.0% | | mean_duration | menu_pelt_4 | 14.5 | 4.74% | | mean_duration | menu_pelt_rampup | 8.3 | -40.31% | | mean_duration | menu_performance | 4.4 | -68.13% | +---------------+-----------------------+-------+-----------+ Jank percentage +-----------+-----------------------+-------+-----------+ | variable | kernel | value | perc_diff | +-----------+-----------------------+-------+-----------+ | jank_perc | menu | 1.5 | 0.0% | | jank_perc | menu_pelt_4 | 2.0 | 30.08% | | jank_perc | menu_pelt_rampup | 0.1 | -93.09% | | jank_perc | menu_performance | 0.1 | -96.29% | +-----------+-----------------------+-------+-----------+ [...] Some variant of this that's tunable at runtime could be workable for the purposes described before. At least this further proves that it's manipulating frequency that's responsible for the results here. --- Kajetan