lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 8 Jul 2020 12:52:53 +0200
From:   Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
To:     Chanwoo Choi <cw00.choi@...sung.com>
Cc:     lukasz.luba@....com, k.konieczny@...sung.com, krzk@...nel.org,
        kgene@...nel.org, s.nawrocki@...sung.com,
        willy.mh.wolff.ml@...il.com, chanwoo@...nel.org,
        myungjoo.ham@...sung.com, kyungmin.park@...sung.com,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 0/2] PM / devfreq: Add delayed timer for polling


Hi Chanwoo,

On 7/3/20 8:26 AM, Chanwoo Choi wrote:
> Add the delayed timer to devfreq framework in order to support
> the periodical polling mode without stop caused by CPU idle state.

Thank you, this patchset looks fine to me and is a step in the right
direction:

Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>

> Some Non-CPU device must need to monitor the device status like
> utilization regardless of CPU state.

This is probably true for all devfreq devices using simple_ondemand
governor by default:

drivers/devfreq/exynos-bus.c
drivers/devfreq/rk3399_dmc.c
drivers/devfreq/tegra20-devfreq.c
drivers/gpu/drm/lima/lima_devfreq.c
drivers/gpu/drm/msm/msm_gpu.c
drivers/gpu/drm/panfrost/panfrost_devfreq.c
drivers/memory/samsung/exynos5422-dmc.c
drivers/scsi/ufs/ufshcd.c

With devfreq device polling being "coupled" to CPU idle state
the devfreq subsystem behavior is completely unpredictable and
unreliable.

It affects both performance (device opp change up happening too
late) and power consumption (device opp change down happening too
late).

It also causes hardware usage counters support to report too high
values (because of CPU idle "coupling" the real polling period
becomes larger than maximum period supported by the counter and
the counter becomes fully "saturated") which negatively affects
power consumption (as has been observed when using Odroid XU3/4).

[ The only upside of using such "coupling" is lowered CPU power
  usage (in some situations) but at the (unacceptable IMHO) cost
  of the correctness of operations of devfreq subsystem. ]

Unfortunately this patchset currently fixes only exynos5422-dmc
devfreq driver. To fix problems for Exynos platforms we need to
also fix exynos-bus devfreq driver.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> - patch1 explains the detailed reason why the delayed timer is required.
> - patch2 initializes that exynos5422-dmc device use delayed timer as default
> instead of deferrable timer.
> 
> Chanwoo Choi (2):
>   PM / devfreq: Add support delayed timer for polling mode
>   memory: samsung: exynos5422-dmc: Use delayed timer as default
> 
>  Documentation/ABI/testing/sysfs-class-devfreq | 12 +++
>  drivers/devfreq/devfreq.c                     | 83 ++++++++++++++++++-
>  drivers/memory/samsung/exynos5422-dmc.c       |  1 +
>  include/linux/devfreq.h                       |  9 ++
>  4 files changed, 104 insertions(+), 1 deletion(-)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ