Re: [RFC PATCH v2 07/13] firmware: arm_scmi: Add notification dispatch and delivery

[Lukasz Luba]

Hi Cristian,

I didn't want to jump into your discussion with Jim in other broader
thread with this small thought, so I added a comment below.

On 2/14/20 3:35 PM, Cristian Marussi wrote:
> Add core SCMI Notifications dispatch and delivery support logic which is
> able, at first, to dispatch well-known received events from the RX ISR to
> the dedicated deferred worker, and then, from there, to final deliver the
> events to the registered users' callbacks.
>
> Dispatch and delivery is just added here, still not enabled.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@xxxxxxx>
> ---
> V1 --> V2
> - splitted out of V1 patch 04
> - moved from IDR maps to real HashTables to store event_handlers
> - simplified delivery logic
> ---
>   drivers/firmware/arm_scmi/notify.c | 242 ++++++++++++++++++++++++++++-
>   drivers/firmware/arm_scmi/notify.h |  22 +++
>   2 files changed, 262 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
> index 1339b6de0a4c..c2341c5304cf 100644
> --- a/drivers/firmware/arm_scmi/notify.c
> +++ b/drivers/firmware/arm_scmi/notify.c
> @@ -48,13 +48,44 @@
>    * particular event coming only from a well defined source (like CPU vs GPU).
>    * When the source is not specified the user callback will be registered for
>    * all existing sources for that event (if any).

[snip]

>   
> @@ -840,6 +1071,11 @@ static struct scmi_notify_ops notify_ops = {
>    */
>   int scmi_notification_init(struct scmi_handle *handle)
>   {
> +	scmi_notify_wq = alloc_workqueue("scmi_notify",
> +					 WQ_UNBOUND | WQ_FREEZABLE, 0);

I think it might limit some platforms. It depends on their workload.
If they have some high priority workloads which rely on this mechanisms,
they might need a RT task here. The workqueues would be scheduled in
CFS, so it depends on workload in there (we might even see 10s ms delays
in scheduling-up them). If we use RT we would grab the CPU from CFS.

It would be good if it is a customization option: which mechanism
to use based on some a parameter. Then we could create:
a) workqueue with the flags above
b) workqueue with WQ_HIGHPRI (limited by minimum nice)
c) kthread_create_worker() with RT/DL/FIFO sched policy
  (with also a parameterized priority)

In default clients might use a) but when they want to tune their
platform, they might change only a parameter in their scmi code,
not maintaining a patch for the RT function out of tree.

Regards,
Lukasz