lkml.org 
[lkml]   [2023]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [POC][RFC][PATCH v2] sched: Extended Scheduler Time Slice
From
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

\
 
 \ /
  Last update: 2023-10-30 19:27    [W:0.441 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site