Re: [PATCH V3 1/4] Sched: Scheduler time slice extension

[Prakash Sangappa]

> On May 2, 2025, at 8:39 AM, Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
> 
> On 2025-05-02 05:05, Peter Zijlstra wrote:
>> On Fri, May 02, 2025 at 01:59:52AM +0000, Prakash Sangappa wrote:
>>> Add support for a thread to request extending its execution time slice on
>>> the cpu. The extra cpu time granted would help in allowing the thread to
>>> complete executing the critical section and drop any locks without getting
>>> preempted. The thread would request this cpu time extension, by setting a
>>> bit in the restartable sequences(rseq) structure registered with the kernel.
>>> 
>>> Kernel will grant a 50us extension on the cpu, when it sees the bit set.
>>> With the help of a timer, kernel force preempts the thread if it is still
>>> running on the cpu when the 50us timer expires. The thread should yield
>>> the cpu by making a system call after completing the critical section.
>>> 
>>> Suggested-by: Peter Ziljstra <peterz@xxxxxxxxxxxxx>
>>> Signed-off-by: Prakash Sangappa <prakash.sangappa@xxxxxxxxxx>
>>> ---
>>> diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h
>>> index c233aae5eac9..900cb75f6a88 100644
>>> --- a/include/uapi/linux/rseq.h
>>> +++ b/include/uapi/linux/rseq.h
>>> @@ -26,6 +26,7 @@ enum rseq_cs_flags_bit {
>>>   RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT_BIT = 0,
>>>   RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL_BIT = 1,
>>>   RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE_BIT = 2,
>>> + RSEQ_CS_FLAG_DELAY_RESCHED_BIT = 3,
>>>  };
>>>    enum rseq_cs_flags {
>>> @@ -35,6 +36,8 @@ enum rseq_cs_flags {
>>>   (1U << RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL_BIT),
>>>   RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE =
>>>   (1U << RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE_BIT),
>>> + RSEQ_CS_FLAG_DELAY_RESCHED =
>>> + (1U << RSEQ_CS_FLAG_DELAY_RESCHED_BIT),
>>>  };
>>>    /*
>>> @@ -128,6 +131,10 @@ struct rseq {
>>>   * - RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
>>>   *     Inhibit instruction sequence block restart on migration for
>>>   *     this thread.
>>> + * - RSEQ_CS_DELAY_RESCHED
>>> + *     Request by user task to try delaying preemption. With
>>> + *     use of a timer, extra cpu time upto 50us is granted for this
>>> + *     thread before being rescheduled.
>>>   */
>>>   __u32 flags;
>> So while it works for testing, this really is a rather crap interface
>> for real because userspace cannot up front tell if its going to work or
>> not.
> 
> I'm also concerned about this. Using so far unused bits within those
> flags is all nice in terms of compactness, but it does not allow
> userspace to query availability of the feature. It will set the flag
> and trigger warnings on older kernels.
> 
> There are a few approaches we can take to make this discoverable:
> 
> A) Expose the supported flags through getauxval(3), e.g. a new
>   AT_RSEQ_CS_FLAGS which would contain a bitmask of the supported
>   rseq_cs flags, or
> 
> B) Add a new "RSEQ_QUERY_CS_FLAGS" flag to sys_rseq @flags parameter. It
>   would return the supported rseq_cs flags.

Option B seems useful. I had thought about something like this.
If this is preferred, I can add the RSEQ_QUERY_CS_FLAGS.

Thanks,
-Prakash.
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com