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=-5.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 2E96AC433E1 for ; Thu, 30 Jul 2020 08:53:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C3A62075F for ; Thu, 30 Jul 2020 08:53:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="eYVboXYb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729101AbgG3Ixj (ORCPT ); Thu, 30 Jul 2020 04:53:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728904AbgG3Ixi (ORCPT ); Thu, 30 Jul 2020 04:53:38 -0400 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D63D2C0619D2 for ; Thu, 30 Jul 2020 01:53:37 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id p1so13440034pls.4 for ; Thu, 30 Jul 2020 01:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=g/F+xHLHXd/8ZK6rRny/UPGuRPEZkN35i9bRzFzL+j4=; b=eYVboXYblrL6RtiIxbJMiDIHoMMoENN+pSuhwWnshhdoyeEgfnz9JQSxsg6wqYbDye 5mVYcgt9RPNn6uHYKOpoXXojVKxAp9E3jUr0PHcH0ulOM8g0uG9A7MXThCy5iMcp7he6 SbD4NW2iPk+FLH0Mx+FfBWyOl4meaY3hDWMQT6815OOzUADDh85sxYIN5e1RGreWm3Fz sONgc+IpTZnyjt3F5jad5IIXviZh4ZyGaVtN/ziIqpk5DDJTnBDnD7O2fgQoPq3+Rje5 ktREp/V3FCN3+X64XSzUbICHx9cZZ0XFwmT+MBPGT//qPw9jF5EaYvvvijHDbedOIsLE MGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=g/F+xHLHXd/8ZK6rRny/UPGuRPEZkN35i9bRzFzL+j4=; b=IZ8UL3ksTqaliOtuq2bm1TU4bVwIg31kcGH2xAsb+aRuWiXDeJ+JrzC7QpzSZc1lil oR6snoO/wpPqABAm+DtXJbuazytYjaaRAT8OtDQir2e+Gu/qxmrTUCC5z4kx28vQP3rk 6o87iwgX98c61VndUCAmVUjLhA4zDpXoqsc1ZX5ETOlxL8ot14r2n1BuVhSA8ROS8txf R49Zx5karkHU5Da9KUifSTPz8M5HMMBBYJ0nqPH9Bx4OYYpRhhQKmDEyTJwofw7jMUzG wXcHxdk5ad8U9ZjY0Ysm5hz6yV7UwFIRV0cwd/HtcW+8z9NRsujfGjkV9wNUrAjiKg0T JNhA== X-Gm-Message-State: AOAM533GhMy3DxqghoC0vJAuCt2YbquWl/JRbYDfZojANs1OVghiAY24 HvGA5A/rWGHIs1A+W5A7ktZUgA== X-Google-Smtp-Source: ABdhPJynGbQhVKvlob9Kyth3PdwegGJXph6cQB/rXc/Czv0Fyoem2apeOrLEwVIDrGiXSlw9TkRh2w== X-Received: by 2002:a17:90a:a502:: with SMTP id a2mr2134344pjq.15.1596099217283; Thu, 30 Jul 2020 01:53:37 -0700 (PDT) Received: from localhost ([106.201.14.19]) by smtp.gmail.com with ESMTPSA id q13sm5531410pjc.21.2020.07.30.01.53.35 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 Jul 2020 01:53:36 -0700 (PDT) Date: Thu, 30 Jul 2020 14:23:33 +0530 From: Viresh Kumar To: Lukasz Luba Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, cristian.marussi@arm.com, rjw@rjwysocki.net Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers Message-ID: <20200730085333.qubrsv7ufqninihd@vireshk-mac-ubuntu> References: <20200729151208.27737-1-lukasz.luba@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200729151208.27737-1-lukasz.luba@arm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29-07-20, 16:12, Lukasz Luba wrote: > The existing CPUFreq framework does not tracks the statistics when the > 'fast switch' is used or when firmware changes the frequency independently > due to e.g. thermal reasons. However, the firmware might track the frequency > changes and expose this to the kernel. > > This patch set aims to introduce CPUfreq statistics gathered by firmware > and retrieved by CPUFreq driver. It would require a new API functions > in the CPUFreq, which allows to poke drivers to get these stats. > > The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends > ARM SCMI protocol layer, patches 3/4, 4/4 modify ARM SCMI CPUFreq driver. Are you doing this for the fast switch case or because your platform actually runs at frequencies which may be different from what cpufreq core has requested ? I am also not sure what these tables should represent, what the cpufreq core has decided for the CPUs or the frequencies we actually run at, as these two can be very different for example if the hardware runs at frequencies which don't match exactly to what is there in the freq table. I believe these are rather to show what cpufreq and its governors are doing with the CPUs. Over that I would like the userspace stats to work exactly as the way they work right now, i.e. capture all transitions from one freq to other, not just time-in-state. Also resetting of the stats from userspace for example. All allocation and printing of the data must be done from stats core, the only thing which the driver would do at the end is updating the stats structure and nothing more. Instead of reading all stats from the firmware, it will be much easier if you can just get the information from the firmware whenever there is a frequency switch and then we can update the stats the way it is done right now. And that would be simple. -- viresh 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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 CBF96C433E0 for ; Thu, 30 Jul 2020 08:55:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 973E62075F for ; Thu, 30 Jul 2020 08:55:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XSDDsZFB"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="eYVboXYb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 973E62075F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bvvvNuJZfxunqo3Hwc0BZLyHDUK3tpYo7TPDCpntP2M=; b=XSDDsZFBy7DcBA4tP0NY4vJUb I4yanCKN+a5mrUnJmH+w8FvF/6mPOsuA541OUrC3dFzbW8UWcGhkoRQXo2ZjrNxCZ38VDA1KzG//c uSASgCqCpMGIMX8xVefhNA7zuo++Uv3R3fWI7EIQXeddRmGWNJUU4Gxv463zg3iacvpFZyphzd/5Q L7ElAy/Pv6AW9EPlCuSJ74cNEdwJ1u+NZ7WZs6oz69GAOzP11kuzMHORxUe3nABE7Byl0vty9tLzx yHtZ8N/XKYJ8SY21XmtHbJT6H/afBfUf0SO/idlscaNkXh9+pXrBpUMmMO37qbDAisikbZE48r+4H 9b4GvCK6g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k14Jq-00008f-LT; Thu, 30 Jul 2020 08:53:42 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k14Jn-00007s-8V for linux-arm-kernel@lists.infradead.org; Thu, 30 Jul 2020 08:53:40 +0000 Received: by mail-pl1-x643.google.com with SMTP id q17so13425750pls.9 for ; Thu, 30 Jul 2020 01:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=g/F+xHLHXd/8ZK6rRny/UPGuRPEZkN35i9bRzFzL+j4=; b=eYVboXYblrL6RtiIxbJMiDIHoMMoENN+pSuhwWnshhdoyeEgfnz9JQSxsg6wqYbDye 5mVYcgt9RPNn6uHYKOpoXXojVKxAp9E3jUr0PHcH0ulOM8g0uG9A7MXThCy5iMcp7he6 SbD4NW2iPk+FLH0Mx+FfBWyOl4meaY3hDWMQT6815OOzUADDh85sxYIN5e1RGreWm3Fz sONgc+IpTZnyjt3F5jad5IIXviZh4ZyGaVtN/ziIqpk5DDJTnBDnD7O2fgQoPq3+Rje5 ktREp/V3FCN3+X64XSzUbICHx9cZZ0XFwmT+MBPGT//qPw9jF5EaYvvvijHDbedOIsLE MGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=g/F+xHLHXd/8ZK6rRny/UPGuRPEZkN35i9bRzFzL+j4=; b=R3Smw71/r6v0gE3PUg6tMQZTw1FSS6G0asFeJYF5s/qt5DYvogVHefpxn5Xy9zhfeS dmuLbP8gPA5/8AcVaK2ujDt6QvU3HeMDcgUji/8hvC27tYeQ68+KAsWfkBdOK/izTDQc xZr2wh4t6BzNjiQb7pra8s28GLwrrR1D/4CM2KzgAnof9e/2SoFj9lvaJoV4KsM+4p6F q2NvF76VSZw54oq169BRXnaF+IJEBjfM4zjs1MrMNQi412u418pdjbfEtd7U8DAmFXlX ASx3S+tfhm/dwlFdVcJEoGKIMMIOWTVAXKGJRz0MEsIKEMbAJy0kq7qvLOuKzblb0xZo 93LQ== X-Gm-Message-State: AOAM533gcwpIhiQGL2SVbgRt6tjbsCCXku14ZdojnCG7Kre2bP5Gu0k6 8iOodjTSdi9Gh7zZzaGnJaGfWg== X-Google-Smtp-Source: ABdhPJynGbQhVKvlob9Kyth3PdwegGJXph6cQB/rXc/Czv0Fyoem2apeOrLEwVIDrGiXSlw9TkRh2w== X-Received: by 2002:a17:90a:a502:: with SMTP id a2mr2134344pjq.15.1596099217283; Thu, 30 Jul 2020 01:53:37 -0700 (PDT) Received: from localhost ([106.201.14.19]) by smtp.gmail.com with ESMTPSA id q13sm5531410pjc.21.2020.07.30.01.53.35 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 Jul 2020 01:53:36 -0700 (PDT) Date: Thu, 30 Jul 2020 14:23:33 +0530 From: Viresh Kumar To: Lukasz Luba Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers Message-ID: <20200730085333.qubrsv7ufqninihd@vireshk-mac-ubuntu> References: <20200729151208.27737-1-lukasz.luba@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200729151208.27737-1-lukasz.luba@arm.com> User-Agent: NeoMutt/20170609 (1.8.3) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200730_045339_404715_058D25B4 X-CRM114-Status: GOOD ( 19.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, cristian.marussi@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 29-07-20, 16:12, Lukasz Luba wrote: > The existing CPUFreq framework does not tracks the statistics when the > 'fast switch' is used or when firmware changes the frequency independently > due to e.g. thermal reasons. However, the firmware might track the frequency > changes and expose this to the kernel. > > This patch set aims to introduce CPUfreq statistics gathered by firmware > and retrieved by CPUFreq driver. It would require a new API functions > in the CPUFreq, which allows to poke drivers to get these stats. > > The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends > ARM SCMI protocol layer, patches 3/4, 4/4 modify ARM SCMI CPUFreq driver. Are you doing this for the fast switch case or because your platform actually runs at frequencies which may be different from what cpufreq core has requested ? I am also not sure what these tables should represent, what the cpufreq core has decided for the CPUs or the frequencies we actually run at, as these two can be very different for example if the hardware runs at frequencies which don't match exactly to what is there in the freq table. I believe these are rather to show what cpufreq and its governors are doing with the CPUs. Over that I would like the userspace stats to work exactly as the way they work right now, i.e. capture all transitions from one freq to other, not just time-in-state. Also resetting of the stats from userspace for example. All allocation and printing of the data must be done from stats core, the only thing which the driver would do at the end is updating the stats structure and nothing more. Instead of reading all stats from the firmware, it will be much easier if you can just get the information from the firmware whenever there is a frequency switch and then we can update the stats the way it is done right now. And that would be simple. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel