linux-kernel - Re: [POC][RFC][PATCH] sched: Extended Scheduler Time Slice

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: <dc5c0574-e7e9-4538-9cd1-528fc0a3e355@efficios.com>
Date:   Wed, 25 Oct 2023 17:56:48 -0400
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Mateusz Guzik <mjguzik@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ankur Arora <ankur.a.arora@...cle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-mm@...ck.org, x86@...nel.org, akpm@...ux-foundation.org,
        luto@...nel.org, bp@...en8.de, dave.hansen@...ux.intel.com,
        hpa@...or.com, mingo@...hat.com, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, willy@...radead.org, mgorman@...e.de,
        jon.grimm@....com, bharata@....com, raghavendra.kt@....com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com,
        jgross@...e.com, andrew.cooper3@...rix.com,
        Joel Fernandes <joel@...lfernandes.org>,
        Youssef Esmat <youssefesmat@...omium.org>,
        Vineeth Pillai <vineethrp@...gle.com>,
        Suleiman Souhlal <suleiman@...gle.com>,
        Ingo Molnar <mingo@...nel.org>,
        Daniel Bristot de Oliveira <bristot@...nel.org>
Subject: Re: [POC][RFC][PATCH] sched: Extended Scheduler Time Slice

On 2023-10-25 15:19, Steven Rostedt wrote:
> On Wed, 25 Oct 2023 14:49:44 -0400
> Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
>>>
>>> No, I wouldn't say it's the same as priority inheritance, which is to help
>>> with determinism and not performance. PI adds overhead but removes
>>> unbounded latency. On average, a non PI mutex is faster than PI mutex, but
>>> can suffer from unbounded priority inversion.
>>
>> AFAIU, this is because PI mutex as implemented by sys futex only boosts the
>> priority of the lock owner. In my proposal here the owner would be able to
>> borrow scheduler slices from the waiters as well.
> 
> I would be worried that that could cause even more scheduling disruption.
> Now we are taking time slices from other CPUs to run the current one?
> 

AFAIU, as we look at the time slices of the waiting tasks, those have meaning
in the context of the runqueue they are currently attached to. We first consume
time slices from tasks sharing the same runqueue as the owner task. Else, I
guess we'd need to migrate the owner task to the runqueue where the time slice
is available so we can use it (but only if migration of the owner task is
allowed to that target cpu).

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com