Re: [RFC] PM / devfreq: Add support for alerts

Hi Akhil,

Actually, this provides custom events for governors, with different
behaviors per each governor, while Matthias's give you the effects not
targeted for a specific governor.

Could you please show me why (the usage cases) you need this
additional event for governors? (You need to implement an event
handler in each governor for this approach).


Cheers,
MyungJoo


On Fri, Jun 1, 2018 at 8:43 PM, Akhil P Oommen [off-list ref] wrote:

On 5/31/2018 11:47 AM, MyungJoo Ham wrote:

quoted

quoted

Currently, DEVFREQ reevaluates the device state periodically and/or
based on the OPP list changes. Private API has to be exposed to allow
the device driver to alert/notify the governor to reevaluate when a new
set of data is available. This makes the governor more coupled to a
particular device driver. We can improve here by exposing a DEVFREQ API
to allow the device drivers to send generic alerts to the governor.

Signed-off-by: Akhil P Oommen <redacted>
---
  drivers/devfreq/devfreq.c  | 21 +++++++++++++++++++++
  drivers/devfreq/governor.h |  1 +
  include/linux/devfreq.h    |  5 +++++
  3 files changed, 27 insertions(+)

Hello Akhil,

It appears that this will have the same effect with
"[PATCH 08/11] PM / devfreq: Make update_devfreq() public" from Matthias
Kaehlcke, doesn't it?


Cheers,
MyungJoo

Hi MyngJoo,

The patch you mentioned is a step in the right direction. But this patch
allows:
1. the governor to decide whether to reevaluate or not. I feel it would be a
better architecture (better Separation of Concern) if that decision is left
to the governor alone.
2. the devices to share multiple types of alerts. A governor may use these
alerts for internal bookkeeping/algorithm and decide to reevaluate policy
when it is necessary. Since we are opening up a new devfreq API for devices,
isn't it better to go for a generic one?

Regards,
Akhil.

-- 
MyungJoo Ham, Ph.D.
S/W Center, Samsung Electronics