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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 2E7EEC8300C for ; Thu, 30 Apr 2020 09:00:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0F8FF20784 for ; Thu, 30 Apr 2020 09:00:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588237221; bh=6KQACPLN/GZpi+FYGmYG62Ze5DkTEi4wV710+OZY2aQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=061VJtkI1ErYpRDC624NdnZx9Eq1EX+TMSOMlm3VQnDurudV9TINSswz3MklQ6GAy GOdeSFga7WfBat3uw27ajJ7sgwiZVbrMMV7vUQzu5STHBXlcB/h3BLEX/NHrRX4CxJ qbP/zNabEgJhAU3uyR6eDb4IU62QvdasfQ2hjJfY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726794AbgD3JAU (ORCPT ); Thu, 30 Apr 2020 05:00:20 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:33853 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726420AbgD3JAS (ORCPT ); Thu, 30 Apr 2020 05:00:18 -0400 Received: by mail-ot1-f67.google.com with SMTP id 72so4306278otu.1; Thu, 30 Apr 2020 02:00:18 -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=6KQACPLN/GZpi+FYGmYG62Ze5DkTEi4wV710+OZY2aQ=; b=H3Jrnez4+57h4GGsGlUKjBUCzgCWRyEy6JDWuCmKOCUwez6SKQkM17Y0T4lZYkM+3/ U4vZQnqImo3eBrs+Ia2oUL/dju4W8ziszY+cnBNYNA47hbTjvd9X0eS6zcQFYB4QTHF0 o+msu24phfMWs/i/Rb9SoKhf1O/TMa12x79vd1Msgn42LseBhvKVz+TbJaJu8uNgpFSL AoZiHg7TzuKitI1VP7RIjEtRs7qV5Y5iQjbDxYfF3Cu/mXxUsL2wzB5TFO/AtqcoWRPG Gv2InbBZN8+ZURT3Kek0CDOPH7tpWuSYn8S9AhwB8MaZg33w6ypVtCqokvlSp4qLKRMP 25EQ== X-Gm-Message-State: AGi0PuZ/6WYvKDfchk5YdRNXQF+OKEYiYpF+ah6eQ9rFZ3kCPO0QYV0r ENSw71cjgK1fJsovF8cELACBs1r5AYHNIpCuL0qQDA== X-Google-Smtp-Source: APiQypION7scbqEm7NDh6Gggg+1C2ij+NE18vee8aBc9XS9X5f4dFoPNeOl0elV99+hw6k1aQNEtvFSivkjKAlKGNyw= X-Received: by 2002:a9d:112:: with SMTP id 18mr1274967otu.167.1588237217674; Thu, 30 Apr 2020 02:00:17 -0700 (PDT) MIME-Version: 1.0 References: <20200424114058.21199-1-benjamin.gaignard@st.com> <7657495.QyJl4BcWH5@kreacher> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 30 Apr 2020 11:00:05 +0200 Message-ID: Subject: Re: [RFC 0/3] Introduce cpufreq minimum load QoS To: Vincent Guittot Cc: "Rafael J. Wysocki" , Benjamin Gaignard , Viresh Kumar , hugues.fruchet@st.com, Mauro Carvalho Chehab , Maxime Coquelin , Alexandre TORGUE , Pavel Machek , Len Brown , "open list:THERMAL" , linux-kernel , linux-media@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, LAK , Patrick Bellasi 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 On Wed, Apr 29, 2020 at 7:08 PM Vincent Guittot wrote: > > On Wed, 29 Apr 2020 at 17:50, Rafael J. Wysocki wrote: > > > > On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote: > > > When start streaming from the sensor the CPU load could remain very low > > > because almost all the capture pipeline is done in hardware (i.e. without > > > using the CPU) and let believe to cpufreq governor that it could use lower > > > frequencies. If the governor decides to use a too low frequency that > > > becomes a problem when we need to acknowledge the interrupt during the > > > blanking time. > > > The delay to ack the interrupt and perform all the other actions before > > > the next frame is very short and doesn't allow to the cpufreq governor to > > > provide the required burst of power. That led to drop the half of the frames. > > > > > > To avoid this problem, DCMI driver informs the cpufreq governors by adding > > > a cpufreq minimum load QoS resquest. > > > > This seems to be addressing a use case that can be addressed with the help of > > utilization clamps with less power overhead. > > Can't freq_qos_update_request() be also used if you don't have cgroup > enabled on your system ? It can. The problem here is that imposing a global minimum frequency limit generally causes the power draw of the system to increase regardless of what is going on, including the CPUs that are not involved in the handling of the interrupt in question. That seems a bit excessive ...