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;
Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4?
To:     Lukasz Luba <lukasz.luba@arm.com>
Cc:     Krzysztof Kozlowski <krzk@kernel.org>,
        Willy Wolff <willy.mh.wolff.ml@gmail.com>,
        Chanwoo Choi <cw00.choi@samsung.com>,
        MyungJoo Ham <myungjoo.ham@samsung.com>,
        Kyungmin Park <kyungmin.park@samsung.com>,
        Kukjin Kim <kgene@kernel.org>, linux-pm@vger.kernel.org,
        "linux-samsung-soc@vger.kernel.org" 
        <linux-samsung-soc@vger.kernel.org>,
        linux-arm-kernel@lists.infradead.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
From:   Sylwester Nawrocki <s.nawrocki@samsung.com>
Message-ID: <708feba7-6b11-4943-1073-a1b5e54b6283@samsung.com>
Date:   Fri, 26 Jun 2020 19:50:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
        Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <4a72fcab-e8da-8323-1fbe-98a6a4b3e0f1@arm.com>
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <20200623164733.qbhua7b6cg2umafj@macmini.local>
        <CAJKOXPeLuq81NC2xZh3y32EB-_APbDAchZD4OW_eCgQKKO+p8w@mail.gmail.com>
        <20200623191129.GA4171@kozik-lap>
        <CGME20200624103308eucas1p188a5fe3cee1916d9430c9971c2dab3a3@eucas1p1.samsung.com>
        <85f5a8c0-7d48-f2cd-3385-c56d662f2c88@arm.com>
        <ef5184ed-00ff-4226-5ece-b0fc8eb16fb6@samsung.com>
        <4a72fcab-e8da-8323-1fbe-98a6a4b3e0f1@arm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Lukasz,

On 25.06.2020 12:02, Lukasz Luba wrote:
> Regarding the 'performance counters overflow interrupts' there is one
> thing worth to keep in mind: variable utilization and frequency.
> For example, in order to make a conclusion in algorithm deciding that
> the device should increase or decrease the frequency, we fix the period
> of observation, i.e. to 500ms. That can cause the long delay if the
> utilization of the device suddenly drops. For example we set an
> overflow threshold to value i.e. 1000 and we know that at 1000MHz
> and full utilization (100%) the counter will reach that threshold
> after 500ms (which we want, because we don't want too many interrupts
> per sec). What if suddenly utilization drops to 2% (i.e. from 5GB/s
> to 250MB/s (what if it drops to 25MB/s?!)), the counter will reach the
> threshold after 50*500ms = 25s. It is impossible just for the counters
> to predict next utilization and adjust the threshold.

Agreed, that's in case when we use just the performance counter (PMCNT)
overflow interrupts. In my experiments I used the (total) cycle counter
(CCNT) overflow interrupts. As that counter is clocked with fixed rate
between devfreq updates it can be used as a timer by pre-loading it with 
initial value depending on current bus frequency. But we could as well 
use some reliable system timer mechanism to generate periodic events. 
I was hoping to use the cycle counter to generate low frequency monitor 
events and the actual performance counters overflow interrupts to detect 
any sudden changes of utilization. However, it seems it cannot be done 
with as simple performance counters HW architecture as on Exynos4412.
It looks like on Exynos5422 we have all what is needed, there is more 
flexibility in selecting the counter source signal, e.g. each counter
can be a clock cycle counter or can count various bus events related to 
actual utilization. Moreover, we could configure the counter gating period 
and alarm interrupts are available for when the counter value drops below 
configured MIN threshold or exceeds configured MAX value.

So it should be possible to configure the HW to generate the utilization 
monitoring events without excessive continuous CPU intervention.
But I'm rather not going to work on the Exynos5422 SoC support at the moment.

> To address that, we still need to have another mechanism (like watchdog)
> which will be triggered just to check if the threshold needs adjustment.
> This mechanism can be a local timer in the driver or a framework
> timer running kind of 'for loop' on all this type of devices (like
> the scheduled workqueue). In both cases in the system there will be
> interrupts, timers (even at workqueues) and scheduling.
> The approach to force developers to implement their local watchdog
> timers (or workqueues) in drivers is IMHO wrong and that's why we have
> frameworks.

Yes, it should be also possible in the framework to use the counter alarm
events where the hardware is advanced enough, in order to avoid excessive 
SW polling.

--
Regards,
Sylwester