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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 9352EC433E0 for ; Wed, 27 May 2020 12:22:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 72A4820899 for ; Wed, 27 May 2020 12:22:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="m/5Y8vGm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728659AbgE0MWl (ORCPT ); Wed, 27 May 2020 08:22:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726644AbgE0MWk (ORCPT ); Wed, 27 May 2020 08:22:40 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26A32C08C5C3 for ; Wed, 27 May 2020 05:22:40 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id v16so28679937ljc.8 for ; Wed, 27 May 2020 05:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9b4AFKGw4ZZqotl5s77CmzWTjWCoCCtFECSbH9IYsSA=; b=m/5Y8vGmTNwpX4AY/6YSPBzyxbV9CKofpxuLOV0rT4OW1WUwRQh+L2hmPkrR89JHho mp29JMpeTbkjSCFWI18PSTIgrgmgOjy6tersXf5zegumqtO4wPcztIOrlczKxAfBaip/ dkflMMQCcfol0dxbIx4Vta1k0hWUb/ffJAZUrQBY2F7BSIYH4RLzFuT9RagreGHhUs+E 3L0R+LudxVmrH/FaiNK0F4I8Vh+kXtqFQu+TEGgkAFqZTdN1Sg6Gr7h26V9rvn/PGWT1 Ny2xAtgPKwRyY+mbbM43KJUc8HGCnx2gqGjVEeQgynYclzEh+vg+qkDRfKBwTGMzbIHG +zqw== 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=9b4AFKGw4ZZqotl5s77CmzWTjWCoCCtFECSbH9IYsSA=; b=kve9g6eBl2NJz9oO9xw1W4l+2BJ8d6WlpZoL61sAAJ3uyNAQbTM/M+QUhYRWyKd/VK O7197HUjFDJ3O80MvlnsGV6JdVb/TT3qM+StIJiW4Nu7LOCGPHp4gsV/eZ+eureXDJ9f ZH3vdrxyrqq9f5o9ZUGAVO1wRpW/CvTdaxT9NhEi3T0fTEm1jx3/6RTxGRWVV5tqJR93 IeygpJfZxWzbjqAuZ39mNElOMfSBakhTPsR1wh8psPYj0yXU9aNMGnD5H8Qzx9XrT6FR ibZ2nB/T7QobA9n9vRp5ZEape6AhS7AIeanuYhy5wKiQyeDL9o/u4PSOK46Foe968KD4 IQ+w== X-Gm-Message-State: AOAM533Rtb+BH7frKhq5j0/dhD9rVPB5kXXVEuuvoudXRGwsSJsDp36k 6qWT+UFJx3Kmkf9g/3rfKoCxIul6bg7AT/QapOBB9w== X-Google-Smtp-Source: ABdhPJxTsWDgeOe5Djkxbz5Vhm5vLbaAAlGQFkDtkkPWtJUSrez+RPSqeMSp1e9eKl58SCBsVQ5ilU3q78cT0eLqwnc= X-Received: by 2002:a2e:9510:: with SMTP id f16mr3179414ljh.111.1590582158421; Wed, 27 May 2020 05:22:38 -0700 (PDT) MIME-Version: 1.0 References: <20200526151619.8779-1-benjamin.gaignard@st.com> In-Reply-To: From: Vincent Guittot Date: Wed, 27 May 2020 14:22:27 +0200 Message-ID: Subject: Re: [RFC RESEND 0/3] Introduce cpufreq minimum load QoS To: Benjamin GAIGNARD Cc: Valentin Schneider , "rjw@rjwysocki.net" , "viresh.kumar@linaro.org" , Hugues FRUCHET , "mchehab@kernel.org" , "mcoquelin.stm32@gmail.com" , Alexandre TORGUE , "pavel@ucw.cz" , "len.brown@intel.com" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-media@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" 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, 27 May 2020 at 13:17, Benjamin GAIGNARD wrote: > > > > On 5/27/20 12:09 PM, Valentin Schneider wrote: > > Hi Benjamin, > > > > On 26/05/20 16:16, Benjamin Gaignard wrote: > >> A first round [1] of discussions and suggestions have already be done on > >> this series but without found a solution to the problem. I resend it to > >> progress on this topic. > >> > > Apologies for sleeping on that previous thread. > > > > So what had been suggested over there was to use uclamp to boost the > > frequency of the handling thread; however if you use threaded IRQs you > > get RT threads, which already get the max frequency by default (at least > > with schedutil). > > > > Does that not work for you, and if so, why? > That doesn't work because almost everything is done by the hardware blocks > without charge the CPU so the thread isn't running. I have done the > tests with schedutil > and ondemand scheduler (which is the one I'm targeting). I have no > issues when using > performance scheduler because it always keep the highest frequencies. IMHO, the only way to ensure a min frequency for anything else than a thread is to use freq_qos_add_request() just like cpufreq cooling device but for the opposite QoS. This can be applied only on the frequency domain of the CPU which handles the interrupt. Have you also checked the wakeup latency of your idle state ? > > > > > >> 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. > >> > >> Benjamin > >> > >> [1] https://lkml.org/lkml/2020/4/24/360 > >> > >> Benjamin Gaignard (3): > >> PM: QoS: Introduce cpufreq minimum load QoS > >> cpufreq: governor: Use minimum load QoS > >> media: stm32-dcmi: Inform cpufreq governors about cpu load needs > >> > >> drivers/cpufreq/cpufreq_governor.c | 5 + > >> drivers/media/platform/stm32/stm32-dcmi.c | 8 ++ > >> include/linux/pm_qos.h | 12 ++ > >> kernel/power/qos.c | 213 ++++++++++++++++++++++++++++++ > >> 4 files changed, 238 insertions(+)