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: <20231026085414.GL31411@noisy.programming.kicks-ass.net>
Date:   Thu, 26 Oct 2023 10:54:14 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Mateusz Guzik <mjguzik@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        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 Wed, Oct 25, 2023 at 01:17:31PM -0400, Steven Rostedt wrote:
> On Wed, 25 Oct 2023 18:24:35 +0200
> Mateusz Guzik <mjguzik@...il.com> wrote:
> 
> > On Wed, Oct 25, 2023 at 11:42:34AM -0400, Mathieu Desnoyers wrote:
> > > On 2023-10-25 10:31, Steven Rostedt wrote:  
> > > > On Wed, 25 Oct 2023 15:55:45 +0200
> > > > Peter Zijlstra <peterz@...radead.org> wrote:  
> > > 
> > > [...]
> > > 
> > > After digging lore for context, here are some thoughts about the actual
> > > proposal: AFAIU the intent here is to boost the scheduling slice for a
> > > userspace thread running with a mutex held so it can complete faster,
> > > and therefore reduce contention.
> > > 
> > > I suspect this is not completely unrelated to priority inheritance
> > > futexes, except that one goal stated by Steven is to increase the
> > > owner slice without requiring to call a system call on the fast-path.
> 
> 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.

Matheusz is right though, what you're asking for is a (limited) priority
ceiling, which is a very primitive form of PI, which itself is a very
specific case of proxy execution :-)

Note that in kernel spinners have this priority ceiling by means of
preempt_disable().

> For this code, I took off my RT hat, and put on my performance hat.

Seems to me you took the brain along with the hat.

You're confusing cost of implementation with concept. Yes full blown PI
is fairly expensive, but the concept is still valid. Priority ceilings
were always an approximation.