Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1596758ybz; Thu, 30 Apr 2020 02:06:25 -0700 (PDT) X-Google-Smtp-Source: APiQypKAyV8A6Sx3siQ+j+eqsWQXESegHJfiaBCUOQzxKE18WAHbk5D3k7g85aUx9Ku4XMO/g/Xo X-Received: by 2002:a17:906:c82b:: with SMTP id dd11mr1687201ejb.216.1588237585504; Thu, 30 Apr 2020 02:06:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588237585; cv=none; d=google.com; s=arc-20160816; b=rGnurXJ1wmiiAjLOtZg8YrBxrziNicWNWta48o+pyLgMniAvBXSxs32EINaq/Hj1zs p8NAfsRaO5N7vFd83wqSJZkiwPsBHGqEGoD052DpQUNNNJPwDokVA9jSfJYA5uJQiQDF Z3feXKXNphlmnFr3Vb7MyB76gJDIKay4OcCtYBCKbp5YXKVVI+xPOkwj28d+ifDC7Fyh 5QD49gl8T8fYhtZqHQ57AWEJy3+jQm9IZ5LckynYNE54ZMhj7F66E+/ltFxrtGg59ZpK m2UG09tG2XAKIyKEejLXC98QGh5VgeO0Q6WhfJujXt7rcGSfpFHkupmZXN4Toy2yABf5 uLIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=IPIctqtbjHbN+c6WsGMnZ4aDcQr0Dn9FvwQoBcXdb4k=; b=0s8G64jJ5/tDHBIjwxUaWe9Ai4gGoQRTHabtnhGHQRIC6rPdKWs2k7Hd+kDaNIXcFu VAmcjmSk20nx+udlMMus5jdjT/2V7wUbtZOdtgx2wN0+xIU3O4p5VKsF94o2pRqJCioD ShgbLlYwO0TbWmlK8zU5Ewyh0Rtsx+wsIZXB7npGp9kdI4G1x3t7JUS21MQX2GJC3U5x IFAhb0fsJf9IRx1CRZ6jeUI66WDB/W6WAzJCeD87dhuA8s8iEr0LFl/OqIgScRJf1mcR TP725F66pC5GC0JmcAEd8WDQvJW4wb1i8g1HvEGKe4SCTqCxvUn81Ew9AHwC214ku+8S gIcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o16si5011718edi.482.2020.04.30.02.06.01; Thu, 30 Apr 2020 02:06:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726853AbgD3JEH (ORCPT + 99 others); Thu, 30 Apr 2020 05:04:07 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:36475 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726420AbgD3JEH (ORCPT ); Thu, 30 Apr 2020 05:04:07 -0400 Received: by mail-oi1-f193.google.com with SMTP id s202so4609412oih.3; Thu, 30 Apr 2020 02:04:06 -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=IPIctqtbjHbN+c6WsGMnZ4aDcQr0Dn9FvwQoBcXdb4k=; b=cWEchaky38a6ftNwmFGRftCwazWO2LC1n86PfbcJIlICh5bPgybL+cuaO+Egs4hFI1 7yLX88FQS8BIrL8l8+f8+9Dx3OWcoosY/YTK3mBu6O4O6zQswgKAwi2PIOhysFur6Ccb 8n5IStch8nTA4R42ojueTOudcJY0TMtdiYwasCBVRMCuFK4J8uR4SGg5oBBQTFHFvdQH hzFTcj7XvyrzuC5YlraFT/28Z7I+19DhIONeOG6CAHnOv+K/og/8ix7ig/5RnRcfamGg c+ik8DIFF62oR7nUNqfSU10IdwsKlGx1+57Z17QpSC52Z93v5E/G/oa7bogjp/76syTL o0fA== X-Gm-Message-State: AGi0PuYlWhPme+BGipgKJv47SeWTe9R83Rqr49Bqvp2T/QD3giPinJhd tt6M52sYai/e6JnCIdlszVH7RwkXcyU5nBix1KU= X-Received: by 2002:aca:aa8c:: with SMTP id t134mr1027807oie.103.1588237445928; Thu, 30 Apr 2020 02:04:05 -0700 (PDT) MIME-Version: 1.0 References: <20200424114058.21199-1-benjamin.gaignard@st.com> <7657495.QyJl4BcWH5@kreacher> <30cdecf9-703a-eb2b-7c2b-f1e21c805add@st.com> <70e743cf-b88e-346a-5114-939b8724c83d@arm.com> <6b5cde14-58b3-045d-9413-223e66b87bf0@st.com> In-Reply-To: <6b5cde14-58b3-045d-9413-223e66b87bf0@st.com> From: "Rafael J. Wysocki" Date: Thu, 30 Apr 2020 11:03:54 +0200 Message-ID: Subject: Re: [RFC 0/3] Introduce cpufreq minimum load QoS To: Benjamin GAIGNARD Cc: Valentin Schneider , "Rafael J. Wysocki" , "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" , 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 Thu, Apr 30, 2020 at 9:53 AM Benjamin GAIGNARD wrote: > > > > On 4/29/20 6:12 PM, Valentin Schneider wrote: > > On 29/04/2020 16:57, Benjamin GAIGNARD wrote: > >> > >> On 4/29/20 5:50 PM, 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. > >> Do mean clamping the policy frequencies ? I may have miss the API to do > >> that... > > IIUC Rafael is referring to uclamp, i.e. scheduler utilization clamping, see: > > > > https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu > > > > The above describes the cgroup interface, note that you can also set clamps > > per task (via sched_setattr()). > > > > One thing that comes to mind however is that schedutil only "sees" the clamps > > of runnable tasks, and from reading your changelog you may not have moments > > without any (i.e. gears are grinding in HW). You'd have to try boosting > > (setting a high uclamp.min) whatever tasks you have on the software side and > > see how it all behaves. > > Relying on userland side means that various applications need to be aware > of this specific hardware case and fix it. I was hoping to find a > solution in side the kernel > to not impact the software side. That's not what I meant. I suppose that the interrupt processing in question takes place in process context and so you may set the lower clamp on the utilization of the task carrying that out. Alternatively, that task may be a deadline one.