Re: [POC][RFC][PATCH v2] sched: Extended Scheduler Time Slice

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2023-10-30 14:19, Steven Rostedt wrote:
> On Mon, 30 Oct 2023 14:05:05 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>> If you have the nesting counter, why do you need the explicit on/off
>> switch ?
> 
> Because I gave up when I found that one of the lwlocks seemed to take a long
> time (pretty much the entire test) or I couldn't find how it was unlocked
> (the code isn't trivial).
> 
> So I just made every unlock disable the extended time slot. I need to go
> back and enable both a counter and an on/off as I now realize that the spin
> locks (called within the lwlock) will disable the extend time before the
> lwlock is released. This should work if I have the spinlocks inc and dec
> (they are straight forward and all locks are associated with an easily
> found unlock), and have the lwlock use bit 31 as an on/off switch.

This extra on/off switch appears to be working around userspace issues.

> Anyway, I would let user space decide what it wants to do, and giving it 31
> bits to say "I'm extended" and let user space come up with how it handles
> those 31 bits.

If this makes it into the RSEQ uapi, RSEQ should state how userspace
should collaborate wrt those bits (e.g. nesting counter protocol), even
though it's not a kernel ABI per se. Otherwise we'll just push this to
libc to specify this, which is odd.

Thanks,

Mathieu

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