Messages in this thread | | | From | Joel Fernandes <> | Subject | Re: [RFC PATCH 07/11] sched: Add proxy execution | Date | Tue, 25 Oct 2022 07:19:35 -0400 |
| |
> On Oct 24, 2022, at 6:33 PM, Qais Yousef <qyousef@layalina.io> 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
| |