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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 15748C433E9 for ; Sun, 7 Feb 2021 13:12:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D41E164E40 for ; Sun, 7 Feb 2021 13:12:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229988AbhBGNMr (ORCPT ); Sun, 7 Feb 2021 08:12:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229872AbhBGNMo (ORCPT ); Sun, 7 Feb 2021 08:12:44 -0500 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 961ECC061756 for ; Sun, 7 Feb 2021 05:12:03 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id j21so7938215wmj.0 for ; Sun, 07 Feb 2021 05:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SISOIgfsxj2z8VwmMOujp6fXedz5KiEYfI9wSyDzvC8=; b=P4s3pEQ6IBAC6p0W66KZ+YpQoB5L/STEiRT+HpSEyF8a4Buf+uBGMK7hwg0OHQWXiM lBfFugB60Ha4/KFYLslXclnx8NAAklo67yXfAe2C/qBcvL4yC93g4AykYrRB+xOwVWKf twHkNJvemF8Nqf+B2fpW79VF5NNHtEKgr5gYt98/qKJVza5AfEi4YSMM7KJZPUszSpGr MXUpFbk4StecqD7EIHJUGgclHLXsP+qIxe1gQ4UfW0BY0GifGGBS69M8LdW5iJjWH7lH xNzqbmy3KKWUj288/cJG9mLMBVL1+PCZN+0bsHs6mbIVjMlA957YCPc3iHkksjr810qt JlHg== 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=SISOIgfsxj2z8VwmMOujp6fXedz5KiEYfI9wSyDzvC8=; b=VP2STc5yM7LfoU40LFGlUlR4xYBYLKf/C+/9HvjzJPctj7tbJgRwqJ2plosTHWvrUy rwKcZKR1RdDnClLS6uUoko4x0HuNyR/EuYUR0UgdQPdN/9vdtnqtBFddP9GoXYO4VXPK PZQmb4N8p1qMad0dYh+6d4Yqv5GRW0R/8rVDuhihKXEXcjY+VPxisYjoWer1PW+8itLS axKT0kH/cBBZeoT1k9XmxYQSAzCnblkP+viLAVFIosYEZ/UHHlcMzOn54MAjuvHLLVnK lnlU1N5apo1ClgT76Yx63g8qzv7FOBgKHcnXaMqPvvHTF2l2098TG8hNmAbbfTEJ3mC+ XZgA== X-Gm-Message-State: AOAM530udIJfvSSEyIqHs+TDWyAU5Pj63N45R2cQLlOpjEcwso6FHgTc giAnlUMjfVAdBECEQGU+QTcfJfCQO8uRvHT0dmo= X-Google-Smtp-Source: ABdhPJzrZkHSlk4UmOBS7bvvUDYA/pEdWgg29Eivq3vpuXVWIHbEegYiV+Lm3MJjh0Saph3nqKpZfT3zj9L3CAEKEYY= X-Received: by 2002:a1c:105:: with SMTP id 5mr11054556wmb.89.1612703522329; Sun, 07 Feb 2021 05:12:02 -0800 (PST) MIME-Version: 1.0 References: <20210127105121.20345-1-lukasz.luba@arm.com> <3d1b4696-0172-f88a-f41f-c66ac3baa429@arm.com> <0afa6299-1c35-ab98-702e-8dcd168bcaac@arm.com> In-Reply-To: From: Qiang Yu Date: Sun, 7 Feb 2021 21:11:51 +0800 Message-ID: Subject: Re: [PATCH] drm/lima: Use delayed timer as default in devfreq profile To: Lukasz Luba Cc: Robin Murphy , lima@lists.freedesktop.org, David Airlie , Christian Hewitt , Linux Kernel Mailing List , dri-devel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Applied to drm-misc-next. Regards, Qiang On Thu, Feb 4, 2021 at 10:24 PM Lukasz Luba wrote: > > > > On 2/4/21 1:39 PM, Robin Murphy wrote: > > On 2021-02-03 02:01, Qiang Yu wrote: > >> On Tue, Feb 2, 2021 at 10:02 PM Lukasz Luba wrote: > >>> > >>> > >>> > >>> On 2/2/21 1:01 AM, Qiang Yu wrote: > >>>> Hi Lukasz, > >>>> > >>>> Thanks for the explanation. So the deferred timer option makes a > >>>> mistake that > >>>> when GPU goes from idle to busy for only one poll periodic, in this > >>>> case 50ms, right? > >>> > >>> Not exactly. Driver sets the polling interval to 50ms (in this case) > >>> because it needs ~3-frame average load (in 60fps). I have discovered the > >>> issue quite recently that on systems with 2 CPUs or more, the devfreq > >>> core is not monitoring the devices even for seconds. Therefore, we might > >>> end up with quite big amount of work that GPU is doing, but we don't > >>> know about it. Devfreq core didn't check <- timer didn't fired. Then > >>> suddenly that CPU, which had the deferred timer registered last time, > >>> is waking up and timer triggers to check our device. We get the stats, > >>> but they might be showing load from 1sec not 50ms. We feed them into > >>> governor. Governor sees the new load, but was tested and configured for > >>> 50ms, so it might try to rise the frequency to max. The GPU work might > >>> be already lower and there is no need for such freq. Then the CPU goes > >>> idle again, so no devfreq core check for next e.g. 1sec, but the > >>> frequency stays at max OPP and we burn power. > >>> > >>> So, it's completely unreliable. We might stuck at min frequency and > >>> suffer the frame drops, or sometimes stuck to max freq and burn more > >>> power when there is no such need. > >>> > >>> Similar for thermal governor, which is confused by this old stats and > >>> long period stats, longer than 50ms. > >>> > >>> Stats from last e.g. ~1sec tells you nothing about real recent GPU > >>> workload. > >> Oh, right, I missed this case. > >> > >>> > >>>> But delayed timer will wakeup CPU every 50ms even when system is > >>>> idle, will this > >>>> cause more power consumption for the case like phone suspend? > >>> > >>> No, in case of phone suspend it won't increase the power consumption. > >>> The device won't be woken up, it will stay in suspend. > >> I mean the CPU is waked up frequently by timer when phone suspend, > >> not the whole device (like the display). > >> > >> Seems it's better to have deferred timer when device is suspended for > >> power saving, > >> and delayed timer when device in working state. User knows this and > >> can use sysfs > >> to change it. > > > > Doesn't devfreq_suspend_device() already cancel any timer work either > > way in that case? > > Correct, the governor should pause the monitoring mechanism (and timer). > > Regards, > Lukasz 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.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B9C26C433DB for ; Sun, 7 Feb 2021 13:12:04 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 78BDB64E43 for ; Sun, 7 Feb 2021 13:12:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78BDB64E43 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E83FF6E17C; Sun, 7 Feb 2021 13:12:03 +0000 (UTC) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by gabe.freedesktop.org (Postfix) with ESMTPS id A6A986E17C; Sun, 7 Feb 2021 13:12:03 +0000 (UTC) Received: by mail-wm1-x32a.google.com with SMTP id f16so10195517wmq.5; Sun, 07 Feb 2021 05:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SISOIgfsxj2z8VwmMOujp6fXedz5KiEYfI9wSyDzvC8=; b=P4s3pEQ6IBAC6p0W66KZ+YpQoB5L/STEiRT+HpSEyF8a4Buf+uBGMK7hwg0OHQWXiM lBfFugB60Ha4/KFYLslXclnx8NAAklo67yXfAe2C/qBcvL4yC93g4AykYrRB+xOwVWKf twHkNJvemF8Nqf+B2fpW79VF5NNHtEKgr5gYt98/qKJVza5AfEi4YSMM7KJZPUszSpGr MXUpFbk4StecqD7EIHJUGgclHLXsP+qIxe1gQ4UfW0BY0GifGGBS69M8LdW5iJjWH7lH xNzqbmy3KKWUj288/cJG9mLMBVL1+PCZN+0bsHs6mbIVjMlA957YCPc3iHkksjr810qt JlHg== 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=SISOIgfsxj2z8VwmMOujp6fXedz5KiEYfI9wSyDzvC8=; b=oiEjF98ccFw7/py4kL+QoUGvxQ7QBmKmcnnHTQHhf1OCuhs8XuFhSjYWCHT8lPnKmg 8GyGyYl/XDYLV2TWrnbjwonvP3gV+guBvrx/EFtyCNmrD1gu85ndCFv2gO/kZ1awPMGr Vztq/qG+KmIZX2f97Sp6XEQf6EJXlVFz5zJmaqvdlh145vu3+LNBafUsKinjzXCvczed l9a/z8k3qxKc1y5loHpYFQz/2I3Mn9YXwDO7LUNyb4sgEVxiJZm1TcClnr/A7FLajYPE edZTx7pB/aN2DPppk2G1lfH8xWF/6aTe9PUIuV00dizHH4Xon5gXXcGWJFbuV0Hggp45 cpTA== X-Gm-Message-State: AOAM531D9LMV2uDNdIdK5ur6F0DWz6zgtol2fYPGT2pyPr/RcEZgorLo jWtFc8MQ28P8PHear4GAziMGxbEQ5mOtbRz5jyATsLuOYzZbaA== X-Google-Smtp-Source: ABdhPJzrZkHSlk4UmOBS7bvvUDYA/pEdWgg29Eivq3vpuXVWIHbEegYiV+Lm3MJjh0Saph3nqKpZfT3zj9L3CAEKEYY= X-Received: by 2002:a1c:105:: with SMTP id 5mr11054556wmb.89.1612703522329; Sun, 07 Feb 2021 05:12:02 -0800 (PST) MIME-Version: 1.0 References: <20210127105121.20345-1-lukasz.luba@arm.com> <3d1b4696-0172-f88a-f41f-c66ac3baa429@arm.com> <0afa6299-1c35-ab98-702e-8dcd168bcaac@arm.com> In-Reply-To: From: Qiang Yu Date: Sun, 7 Feb 2021 21:11:51 +0800 Message-ID: Subject: Re: [PATCH] drm/lima: Use delayed timer as default in devfreq profile To: Lukasz Luba X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lima@lists.freedesktop.org, David Airlie , Christian Hewitt , Linux Kernel Mailing List , dri-devel , Robin Murphy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Applied to drm-misc-next. Regards, Qiang On Thu, Feb 4, 2021 at 10:24 PM Lukasz Luba wrote: > > > > On 2/4/21 1:39 PM, Robin Murphy wrote: > > On 2021-02-03 02:01, Qiang Yu wrote: > >> On Tue, Feb 2, 2021 at 10:02 PM Lukasz Luba wrote: > >>> > >>> > >>> > >>> On 2/2/21 1:01 AM, Qiang Yu wrote: > >>>> Hi Lukasz, > >>>> > >>>> Thanks for the explanation. So the deferred timer option makes a > >>>> mistake that > >>>> when GPU goes from idle to busy for only one poll periodic, in this > >>>> case 50ms, right? > >>> > >>> Not exactly. Driver sets the polling interval to 50ms (in this case) > >>> because it needs ~3-frame average load (in 60fps). I have discovered the > >>> issue quite recently that on systems with 2 CPUs or more, the devfreq > >>> core is not monitoring the devices even for seconds. Therefore, we might > >>> end up with quite big amount of work that GPU is doing, but we don't > >>> know about it. Devfreq core didn't check <- timer didn't fired. Then > >>> suddenly that CPU, which had the deferred timer registered last time, > >>> is waking up and timer triggers to check our device. We get the stats, > >>> but they might be showing load from 1sec not 50ms. We feed them into > >>> governor. Governor sees the new load, but was tested and configured for > >>> 50ms, so it might try to rise the frequency to max. The GPU work might > >>> be already lower and there is no need for such freq. Then the CPU goes > >>> idle again, so no devfreq core check for next e.g. 1sec, but the > >>> frequency stays at max OPP and we burn power. > >>> > >>> So, it's completely unreliable. We might stuck at min frequency and > >>> suffer the frame drops, or sometimes stuck to max freq and burn more > >>> power when there is no such need. > >>> > >>> Similar for thermal governor, which is confused by this old stats and > >>> long period stats, longer than 50ms. > >>> > >>> Stats from last e.g. ~1sec tells you nothing about real recent GPU > >>> workload. > >> Oh, right, I missed this case. > >> > >>> > >>>> But delayed timer will wakeup CPU every 50ms even when system is > >>>> idle, will this > >>>> cause more power consumption for the case like phone suspend? > >>> > >>> No, in case of phone suspend it won't increase the power consumption. > >>> The device won't be woken up, it will stay in suspend. > >> I mean the CPU is waked up frequently by timer when phone suspend, > >> not the whole device (like the display). > >> > >> Seems it's better to have deferred timer when device is suspended for > >> power saving, > >> and delayed timer when device in working state. User knows this and > >> can use sysfs > >> to change it. > > > > Doesn't devfreq_suspend_device() already cancel any timer work either > > way in that case? > > Correct, the governor should pause the monitoring mechanism (and timer). > > Regards, > Lukasz _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel