Re: [PATCH 03/13] ANDROID: binder: add support for RT prio inheritance.

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 25 Aug 2017, Martijn Coenen wrote:

> Adds support for SCHED_BATCH/SCHED_FIFO/SCHED_RR
> priority inheritance.

Sorry, but this has not much to do with real priority inheritance.

It's a poor mans pseudo PI implementation. What I can't see from the sparse
changelog is how all of this is supposed to work.

My interpretation of it is, that you need to make sure that the other
thread in that IPC mechanism gets boosted enough to not block the thread
which needs a reply or action.

Therefor you create a unreadable maze of capability checks and other things
which do not make any sense to me due to lack of comments and something
which explains the big picture.

The whole thing looks wrong and engineered sideways circumventing the
existing facilities and making weird assumptions about priority settings.

As fair as I can see this is pretty much similar to stuff like RCU boosting
or other mechanisms which temporarily elevate the priority of a different
task.

I have no idea about the inner workings of all this, so let me describe my
understanding and ask a few questions.

Current state:

  1) thread queues work to worker via binder

  2) thread waits for the work to complete (I deduced that from a stray
     comment about sync work)

If the waiting thread is a high priority thread it might wait for a long
time if the worker thread is low priority or SCHED_OTHER.

Desired state:

  1) thread queues work to worker thread via binder
  
  1a) thread boosts the worker to its own priority

  2) thread waits for the work to complete

  2a) worker completes and drops priority boost

Is that about right?

If yes, then this whole thing can be simplified via the existing rtmutex
mechanism:

  1) thread creates work

  1a) thread proxy locks an rtmutex embedded in the work on behalf of the
      worker

  1b) thread queues work

  2) thread locks the rtmutex embedded in the work and blocks. This
     automatically includes the existing priority inheritance machinery
     without further voodoo.

  2a) worker runs with the inherited priority and completes the work

  2b) worker unlocks the rtmutex embedded in the work and drops priority

I probably miss something here, but I'm happy to read some proper
explanation how all of this is supposed to work.

Thanks,

	tglx