Re: [RFC PATCH 07/11] sched: Add proxy execution

[Joel Fernandes]

> On Oct 24, 2022, at 6:33 PM, Qais Yousef <qyousef@xxxxxxxxxxx> wrote:
> 
> On 10/17/22 09:26, Peter Zijlstra wrote:
> 
>> Additionally, the highest priotiy waiter will get the lock next.
> 
> True for RT. But for CFS, priority is share and there will be no guarantee the
> 'highest priority' task will run as soon as the lock is released to grab it,
> no?

But the mutex lock owner should have done a wake_up in the mutex unlock path, which is arranged in FIFO order, if I am not mistaken. Subsequently the scheduler will at least get a chance to see if the thing that is waiting for the lock is of higher priority, at the next preemption point.

If it did not get to run, I don’t think that’s an issue — it was not highest priority as far as the scheduler is concerned. No?

Steve was teaching me some of this code recently, he could chime in :)

> For example I can envisage:
> 
>    +--------+----------------+--------+--------
>    |  p0    |       p1       |   p0   |   p1
>    +--------+----------------+--------+--------
>              ^  ^                 ^      ^ ^
>          |  |                 |      | | 
>              |  |                 |      | Fails to hold the lock
>      holds lock        releases lock | and proxy execs for p0 again
>             |                        |
>         |                        |
>         tries to hold lock         holds lock again
>         proxy execs for p0
> 
> The notion of priority in CFS as it stands doesn't help in providing any
> guarantees in who will be able to hold the lock next. I haven't looked at the
> patches closely, so this might be handled already. I think the situation will
> be worse if there're more tasks contending for the lock. Priority will
> influences the chances, but the end result who holds the lock next is
> effectively random, AFAICT.

The wake up during unlock is FIFO order of waiters though. So that’s deterministic.

> I had a conversation once with an app developer who came from iOS world and
> they were confused why their higher priority task is not preempting the lower
> priority one when they ported it to Android.
> 
> I wonder sometimes if we need to introduce a true notion of priority for CFS.
> I don't see why an app developer who would like to create 3 tasks and give them
> strict priority order relative to each others can't do that. At the moment they
> have little option in controlling execution order.

I want to talk more about this with you, I am actually working on something similar. Let’s talk ;)

Thanks,

- Joel


> 
> Actually I think we need two types of priorities:
> 
>    * global priorities for a sys admin to say which apps are more
>      important to run over other apps. Or fairly share it if
>      equal priority.
>    * local priorities for an app to control which of its tasks are more
>      important to run over other tasks it owns.
> 
> The concept of share doesn't allow controlling execution order - and forces us
> to look at things like latency_nice to, somewhat, overcome this limitation.
> 
> 
> Thanks
> 
> --
> Qais Yousef