Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Joel Fernandes <joel@joelfernandes.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 07/11] sched: Add proxy execution
Date:   Tue, 25 Oct 2022 07:19:35 -0400
Message-Id: <7BBED338-D158-401B-8A6B-FDBD9FC03973@joelfernandes.org>
References: <20221024223324.2jgwrmnqxpgw2m67@airbuntu>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Connor O'Brien <connoro@google.com>,
        linux-kernel@vger.kernel.org, kernel-team@android.com,
        John Stultz <jstultz@google.com>,
        Qais Yousef <qais.yousef@arm.com>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Will Deacon <will@kernel.org>,
        Waiman Long <longman@redhat.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        "Paul E . McKenney" <paulmck@kernel.org>, youssefesmat@google.com
In-Reply-To: <20221024223324.2jgwrmnqxpgw2m67@airbuntu>
To:     Qais Yousef <qyousef@layalina.io>
Precedence: bulk


> On Oct 24, 2022, at 6:33 PM, Qais Yousef <qyousef@layalina.io> wrote:
>=20
> =EF=BB=BFOn 10/17/22 09:26, Peter Zijlstra wrote:
>=20
>> Additionally, the highest priotiy waiter will get the lock next.
>=20
> 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 i=
t,
> 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 sc=
heduler will at least get a chance to see if the thing that is waiting for t=
he lock is of higher priority, at the next preemption point.

If it did not get to run, I don=E2=80=99t think that=E2=80=99s an issue =E2=80=
=94 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:
>=20
>    +--------+----------------+--------+--------
>    |  p0    |       p1       |   p0   |   p1
>    +--------+----------------+--------+--------
>              ^  ^                 ^      ^ ^
>          |  |                 |      | |=20
>              |  |                 |      | 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
>=20
> 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 t=
he
> patches closely, so this might be handled already. I think the situation w=
ill
> 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=E2=80=99s=
 deterministic.

> I had a conversation once with an app developer who came from iOS world an=
d
> they were confused why their higher priority task is not preempting the lo=
wer
> priority one when they ported it to Android.
>=20
> I wonder sometimes if we need to introduce a true notion of priority for C=
FS.
> 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 s=
imilar. Let=E2=80=99s talk ;)

Thanks,

- Joel


>=20
> Actually I think we need two types of priorities:
>=20
>    * 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.
>=20
> The concept of share doesn't allow controlling execution order - and force=
s us
> to look at things like latency_nice to, somewhat, overcome this limitation=
.
>=20
>=20
> Thanks
>=20
> --
> Qais Yousef