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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <7BBED338-D158-401B-8A6B-FDBD9FC03973@joelfernandes.org>
Date:   Tue, 25 Oct 2022 07:19:35 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Qais Yousef <qyousef@...alina.io>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Connor O'Brien <connoro@...gle.com>,
        linux-kernel@...r.kernel.org, kernel-team@...roid.com,
        John Stultz <jstultz@...gle.com>,
        Qais Yousef <qais.yousef@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        "Paul E . McKenney" <paulmck@...nel.org>, youssefesmat@...gle.com
Subject: Re: [RFC PATCH 07/11] sched: Add proxy execution



> On Oct 24, 2022, at 6:33 PM, Qais Yousef <qyousef@...alina.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