Re: [PATCH 1/2] memory: samsung: exynos5422-dmc: Adjust polling interval and uptreshold

From: Lukasz Luba
Date: Fri Jul 10 2020 - 09:41:37 EST




On 7/10/20 2:19 PM, Krzysztof Kozlowski wrote:
On Fri, Jul 10, 2020 at 03:13:18PM +0200, Marek Szyprowski wrote:
Hi Lukasz,

On 10.07.2020 10:34, Lukasz Luba wrote:
Hi Chanwoo,

On 7/9/20 5:08 AM, Chanwoo Choi wrote:
Hi Lukasz,

On 7/9/20 12:34 AM, Lukasz Luba wrote:
In order to react faster and make better decisions under some
workloads,
benchmarking the memory subsystem behavior, adjust the polling interval
and upthreshold value used by the simple_ondemand governor.

Reported-by: Willy Wolff <willy.mh.wolff.ml@xxxxxxxxx>
Signed-off-by: Lukasz Luba <lukasz.luba@xxxxxxx>
---
 drivers/memory/samsung/exynos5422-dmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/samsung/exynos5422-dmc.c
b/drivers/memory/samsung/exynos5422-dmc.c
index 93e9c2429c0d..e03ee35f0ab5 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -1466,10 +1466,10 @@ static int exynos5_dmc_probe(struct
platform_device *pdev)
ÂÂÂÂÂÂÂÂÂÂ * Setup default thresholds for the devfreq governor.
ÂÂÂÂÂÂÂÂÂÂ * The values are chosen based on experiments.
ÂÂÂÂÂÂÂÂÂÂ */
-ÂÂÂÂÂÂÂ dmc->gov_data.upthreshold = 30;
+ÂÂÂÂÂÂÂ dmc->gov_data.upthreshold = 10;
ÂÂÂÂÂÂÂÂÂ dmc->gov_data.downdifferential = 5;
 - exynos5_dmc_df_profile.polling_ms = 500;
+ÂÂÂÂÂÂÂ exynos5_dmc_df_profile.polling_ms = 100;
ÂÂÂÂÂ }


Reviewed-by: Chanwoo Choi <cw00.choi@xxxxxxxxxxx>


Thank you for the review. Do you think this patch could go through
your tree together with your patches?

I don't know Krzysztof's opinion about the patch 2/2, but
I would expect, assuming the patch itself is correct, he would
like to take it into his next/dt branch.

Is there really a need to remove the interrupts property? imho they are
correct hw description, it just a matter of the driver to use or not to
use them.

Marek, I agree with you, they are correct hw description. Unfortunately,
I don't have TRM to experiment and maybe fix the interrupt mode code.


That's actually very good point. I would also prefer to leave them.
However I understood that driver chooses mode depending on the property.

Correct


In such case, maybe as you said, let's switch to polling mode
unconditionally?

I can make happen that the polling mode will be unconditionally
set as default.

Do you think that the interrupt mode code can still stay in the
driver, because maybe in future could be fixed?



Best regards,
Krzysztof