Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3689722pxb; Mon, 1 Feb 2021 01:58:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJzqW9DNPax4sCaYsLp0SxLTKdWYhVWK1Apd+pI8veyk39iPryZI6arfKrGFGb3vZC2OnyUE X-Received: by 2002:a17:906:8046:: with SMTP id x6mr16927526ejw.351.1612173481004; Mon, 01 Feb 2021 01:58:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612173480; cv=none; d=google.com; s=arc-20160816; b=SmnbYfzQ9ei5pBBiprTdSNxL3hVWaitHV+RWgsHRnBERk7/+UhzeD2iezCANR4myJx vmYhGFP6TvvWh24ynvZ+ECg1I/UKicCFhF3ZggaB71TsvqnqT6OQFwyy8OM3P8IF5jO+ Q8BVbaUGl+9FxPOCnTIw0VzZpDeB6LVsuDxcHoLZWRtDr3Aa8NljfAUq4yVM9bKk8OAj zPxZrFAftu/hMgZxfhQKVSKIZjSgETIqNKU4WAseafH8WtuLaNJceLSFWMq3xO7cMEUC pXVMy6A599bRHyqLez3772KM6iauS07HBegDg5t8Ajb4IdtkH/NMaovctAidclJ3f1WZ UW9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=XoZ5WQCuM/Nfng1US82jwqgnIWif1mXXWYH0Li/cOEY=; b=mjpfxzdqbZL0OQxfN55TJIvsIjYNxI9mz7670g0GEahF/H+Byjmzml/vNHWuF+N+Hp erLrwdIcbISw9bAwM/5lVFfMiMs8feQPUY1Ztlw4kYj7m6+Vz5NXQLFHPel7llUQuj0L zG/8yDayW19Sn2ZcWbL7ch4we1qdMXeFakvfXmwqej9Kw8pAoqv2GzJFKlsXnk9tfCdf LBo2pLBRFzA6OKjOinu32DHRLn0wXXRVjfumfn/R0I8+ape/SvKnmn9uOFGHem50s23/ AFmDG1XgktMVirfr1KWNK3BN3ZCPMy8Tkvv+DYOIhHWlooSeyymj+InfbFE1jtd8cbkR zUyg== 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ak11si1777114ejc.352.2021.02.01.01.57.36; Mon, 01 Feb 2021 01:58:00 -0800 (PST) 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232975AbhBAJyG (ORCPT + 99 others); Mon, 1 Feb 2021 04:54:06 -0500 Received: from foss.arm.com ([217.140.110.172]:54570 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232972AbhBAJyD (ORCPT ); Mon, 1 Feb 2021 04:54:03 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5300A101E; Mon, 1 Feb 2021 01:53:17 -0800 (PST) Received: from [10.57.8.191] (unknown [10.57.8.191]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AD2FE3F718; Mon, 1 Feb 2021 01:53:15 -0800 (PST) Subject: Re: [PATCH] drm/lima: Use delayed timer as default in devfreq profile To: Qiang Yu Cc: Linux Kernel Mailing List , David Airlie , Daniel Vetter , lima@lists.freedesktop.org, dri-devel , christianshewitt@gmail.com References: <20210127105121.20345-1-lukasz.luba@arm.com> From: Lukasz Luba Message-ID: <3d1b4696-0172-f88a-f41f-c66ac3baa429@arm.com> Date: Mon, 1 Feb 2021 09:53:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Qiang, On 1/30/21 1:51 PM, Qiang Yu wrote: > Thanks for the patch. But I can't observe any difference on glmark2 > with or without this patch. > Maybe you can provide other test which can benefit from it. This is a design problem and has impact on the whole system. There is a few issues. When the device is not checked and there are long delays between last check and current, the history is broken. It confuses the devfreq governor and thermal governor (Intelligent Power Allocation (IPA)). Thermal governor works on stale stats data and makes stupid decisions, because there is no new stats (device not checked). Similar applies to devfreq simple_ondemand governor, where it 'tires' to work on a loooong period even 3sec and make prediction for the next frequency based on it (which is broken). How it should be done: constant reliable check is needed, then: - period is guaranteed and has fixed size, e.g 50ms or 100ms. - device status is quite recent so thermal devfreq cooling provides 'fresh' data into thermal governor This would prevent odd behavior and solve the broken cases. > > Considering it will wake up CPU more frequently, and user may choose > to change this by sysfs, > I'd like to not apply it. The deferred timer for GPU is wrong option, for UFS or eMMC makes more sense. It's also not recommended for NoC busses. I've discovered that some time ago and proposed to have option to switch into delayed timer. Trust me, it wasn't obvious to find out that this missing check has those impacts. So the other engineers or users might not know that some problems they faces (especially when the device load is changing) is due to this delayed vs deffered timer and they will change it in the sysfs. Regards, Lukasz > > Regards, > Qiang >