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: <48573a20-19d9-4400-a35e-86bf3dc043ad@efficios.com>
Date:   Wed, 25 Oct 2023 10:53:38 -0400
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     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 10:31, Steven Rostedt wrote:
> On Wed, 25 Oct 2023 15:55:45 +0200
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
>> On Wed, Oct 25, 2023 at 08:54:34AM -0400, Steven Rostedt wrote:
>>
>>> I didn't want to overload that for something completely different. This is
>>> not a "restartable sequence".
>>
>> Your hack is arguably worse. At least rseq already exists and most
>> threads will already have it set up if you have a recent enough glibc.
> 
> I don't expect that file to be the final solution. I can look at the rseq
> code, but I really hate to overload that. I'm thinking perhaps another
> system call, or what the hell, add another ioctl like feature to prctl()!
> Actually, prctl() may be the proper place for this.
> 

I don't have an informed opinion on whether the proposed heuristic is a 
good idea or not, but it should definitely be implemented as an 
extension to rseq as suggested by Peter. I've even made the whole rseq 
ABI extensible to accommodate those additional use-cases.

In the initial rounds of rseq implementation, I even called rseq "kTLS" 
because I expected it to be extended and eventually become an ABI that 
contains various per-thread fields which are shared between kernel and 
userspace.

So don't let the specific naming of the rseq system call stop you from 
extending it for other purposes when per-thread shared memory between 
kernel and userspace is needed. Setting up various per-thread areas like 
this on thread creation is not free: it requires additional system calls 
on thread creation. It really makes no sense to have more than one.

Thanks,

Mathieu

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