[PATCH 0/2] Scheduler time extension

[PATCH 0/2] Scheduler time extension

[Prakash Sangappa]

Follow up to discussion in [1], posting these patches.
They are based on use of the restartable sequences(rseq) for API.

However, currently the discussion is on thread [2] in response to patch
posted by Steven. Mainly about whether this feature should be applicable
only to normal threads(SCHED_OTHER) under PREEMPT_LAZY preemption model
or keep it independent of the preemption method.

[1] https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com/
[2] https://lore.kernel.org/all/20250131225837.972218232@goodmis.org/

Prakash Sangappa (2):
  Sched: Scheduler time slice extension
  Sched: Add scheduler stat for cpu time slice extension

 include/linux/entry-common.h | 11 +++++--
 include/linux/sched.h        | 20 +++++++++++++
 include/uapi/linux/rseq.h    |  5 ++++
 kernel/entry/common.c        | 15 ++++++----
 kernel/rseq.c                | 57 ++++++++++++++++++++++++++++++++++++
 kernel/sched/core.c          | 21 +++++++++++++
 kernel/sched/debug.c         |  1 +
 kernel/sched/syscalls.c      |  5 ++++
 8 files changed, 127 insertions(+), 8 deletions(-)

-- 
2.43.5

[PATCH 1/2] Sched: Scheduler time slice extension

[Prakash Sangappa]

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 after completing the critical section.

Suggested-by: Peter Ziljstra <peterz@infradead.org>
Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
---
 include/linux/entry-common.h | 11 +++++--
 include/linux/sched.h        | 18 ++++++++++++
 include/uapi/linux/rseq.h    |  5 ++++
 kernel/entry/common.c        | 15 ++++++----
 kernel/rseq.c                | 56 ++++++++++++++++++++++++++++++++++++
 kernel/sched/core.c          | 16 +++++++++++
 kernel/sched/syscalls.c      |  5 ++++
 7 files changed, 118 insertions(+), 8 deletions(-)

diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h
index fc61d0205c97..cec343f95210 100644
--- a/include/linux/entry-common.h
+++ b/include/linux/entry-common.h
@@ -303,7 +303,8 @@ void arch_do_signal_or_restart(struct pt_regs *regs);
  * exit_to_user_mode_loop - do any pending work before leaving to user space
  */
 unsigned long exit_to_user_mode_loop(struct pt_regs *regs,
-				     unsigned long ti_work);
+				     unsigned long ti_work,
+				     bool irq);
 
 /**
  * exit_to_user_mode_prepare - call exit_to_user_mode_loop() if required
@@ -315,7 +316,8 @@ unsigned long exit_to_user_mode_loop(struct pt_regs *regs,
  *    EXIT_TO_USER_MODE_WORK are set
  * 4) check that interrupts are still disabled
  */
-static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs)
+static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs,
+						bool irq)
 {
 	unsigned long ti_work;
 
@@ -326,7 +328,10 @@ static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs)
 
 	ti_work = read_thread_flags();
 	if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK))
-		ti_work = exit_to_user_mode_loop(regs, ti_work);
+		ti_work = exit_to_user_mode_loop(regs, ti_work, irq);
+
+	if (irq)
+		rseq_delay_resched_fini();
 
 	arch_exit_to_user_mode_prepare(regs, ti_work);
 
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 599f077b8019..75abe260de72 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -326,6 +326,7 @@ extern int __must_check io_schedule_prepare(void);
 extern void io_schedule_finish(int token);
 extern long io_schedule_timeout(long timeout);
 extern void io_schedule(void);
+extern void hrtick_local_start(u64 delay);
 
 /**
  * struct prev_cputime - snapshot of system and user cputime
@@ -930,6 +931,9 @@ struct task_struct {
 	struct plist_node		pushable_tasks;
 	struct rb_node			pushable_dl_tasks;
 #endif
+#ifdef CONFIG_RSEQ
+	unsigned			rseq_sched_delay:1;
+#endif
 
 	struct mm_struct		*mm;
 	struct mm_struct		*active_mm;
@@ -2221,6 +2225,20 @@ static inline bool owner_on_cpu(struct task_struct *owner)
 unsigned long sched_cpu_util(int cpu);
 #endif /* CONFIG_SMP */
 
+#ifdef CONFIG_RSEQ
+
+extern bool rseq_delay_resched(void);
+extern void rseq_delay_resched_fini(void);
+extern void rseq_delay_resched_tick(void);
+
+#else
+
+static inline bool rseq_delay_resched(void) { return false; }
+static inline void rseq_delay_resched_fini(void) { }
+static inline void rseq_delay_resched_tick(void) { }
+
+#endif
+
 #ifdef CONFIG_SCHED_CORE
 extern void sched_core_free(struct task_struct *tsk);
 extern void sched_core_fork(struct task_struct *p);
diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h
index c233aae5eac9..ec3b45f32bc8 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,8 @@ struct rseq {
 	 * - RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
 	 *     Inhibit instruction sequence block restart on migration for
 	 *     this thread.
+	 * - RSEQ_CS_DELAY_RESCHED
+	 *     Try delay resched...
 	 */
 	__u32 flags;
 
diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index 6b7ff1bc1b9b..0db3039345ac 100644
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -89,7 +89,8 @@ void __weak arch_do_signal_or_restart(struct pt_regs *regs) { }
  * @ti_work:	TIF work flags as read by the caller
  */
 __always_inline unsigned long exit_to_user_mode_loop(struct pt_regs *regs,
-						     unsigned long ti_work)
+						     unsigned long ti_work,
+						     bool irq)
 {
 	/*
 	 * Before returning to user space ensure that all pending work
@@ -99,8 +100,12 @@ __always_inline unsigned long exit_to_user_mode_loop(struct pt_regs *regs,
 
 		local_irq_enable_exit_to_user(ti_work);
 
-		if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY))
-			schedule();
+		if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY)) {
+		       if (irq && rseq_delay_resched())
+			       clear_tsk_need_resched(current);
+		       else
+			       schedule();
+		}
 
 		if (ti_work & _TIF_UPROBE)
 			uprobe_notify_resume(regs);
@@ -208,7 +213,7 @@ static __always_inline void __syscall_exit_to_user_mode_work(struct pt_regs *reg
 {
 	syscall_exit_to_user_mode_prepare(regs);
 	local_irq_disable_exit_to_user();
-	exit_to_user_mode_prepare(regs);
+	exit_to_user_mode_prepare(regs, false);
 }
 
 void syscall_exit_to_user_mode_work(struct pt_regs *regs)
@@ -232,7 +237,7 @@ noinstr void irqentry_enter_from_user_mode(struct pt_regs *regs)
 noinstr void irqentry_exit_to_user_mode(struct pt_regs *regs)
 {
 	instrumentation_begin();
-	exit_to_user_mode_prepare(regs);
+	exit_to_user_mode_prepare(regs, true);
 	instrumentation_end();
 	exit_to_user_mode();
 }
diff --git a/kernel/rseq.c b/kernel/rseq.c
index 442aba29bc4c..9f83d47253ce 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -426,6 +426,62 @@ void __rseq_handle_notify_resume(struct ksignal *ksig, struct pt_regs *regs)
 	force_sigsegv(sig);
 }
 
+bool rseq_delay_resched(void)
+{
+	struct task_struct *t = current;
+	u32 flags;
+
+	if (!IS_ENABLED(CONFIG_SCHED_HRTICK))
+		return false;
+
+	if (!t->rseq)
+		return false;
+
+	if (t->rseq_sched_delay)
+		return false;
+
+	if (copy_from_user_nofault(&flags, &t->rseq->flags, sizeof(flags)))
+		return false;
+
+	if (!(flags & RSEQ_CS_FLAG_DELAY_RESCHED))
+		return false;
+
+	flags &= ~RSEQ_CS_FLAG_DELAY_RESCHED;
+	if (copy_to_user_nofault(&t->rseq->flags, &flags, sizeof(flags)))
+		return false;
+
+	t->rseq_sched_delay = 1;
+
+	return true;
+}
+
+void rseq_delay_resched_fini(void)
+{
+#ifdef CONFIG_SCHED_HRTICK
+	extern void hrtick_local_start(u64 delay);
+	struct task_struct *t = current;
+	/*
+	 * IRQs off, guaranteed to return to userspace, start timer on this CPU
+	 * to limit the resched-overdraft.
+	 *
+	 * If your critical section is longer than 50 us you get to keep the
+	 * pieces.
+	 */
+	if (t->rseq_sched_delay)
+		hrtick_local_start(50 * NSEC_PER_USEC);
+#endif
+}
+
+void rseq_delay_resched_tick(void)
+{
+#ifdef CONFIG_SCHED_HRTICK
+	struct task_struct *t = current;
+
+	if (t->rseq_sched_delay)
+		set_tsk_need_resched(t);
+#endif
+}
+
 #ifdef CONFIG_DEBUG_RSEQ
 
 /*
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 165c90ba64ea..cee50e139723 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -823,6 +823,7 @@ void update_rq_clock(struct rq *rq)
 
 static void hrtick_clear(struct rq *rq)
 {
+	rseq_delay_resched_tick();
 	if (hrtimer_active(&rq->hrtick_timer))
 		hrtimer_cancel(&rq->hrtick_timer);
 }
@@ -838,6 +839,8 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
 
 	WARN_ON_ONCE(cpu_of(rq) != smp_processor_id());
 
+	rseq_delay_resched_tick();
+
 	rq_lock(rq, &rf);
 	update_rq_clock(rq);
 	rq->donor->sched_class->task_tick(rq, rq->curr, 1);
@@ -911,6 +914,16 @@ void hrtick_start(struct rq *rq, u64 delay)
 
 #endif /* CONFIG_SMP */
 
+void hrtick_local_start(u64 delay)
+{
+	struct rq *rq = this_rq();
+	struct rq_flags rf;
+
+	rq_lock(rq, &rf);
+	hrtick_start(rq, delay);
+	rq_unlock(rq, &rf);
+}
+
 static void hrtick_rq_init(struct rq *rq)
 {
 #ifdef CONFIG_SMP
@@ -6718,6 +6731,9 @@ static void __sched notrace __schedule(int sched_mode)
 picked:
 	clear_tsk_need_resched(prev);
 	clear_preempt_need_resched();
+#ifdef CONFIG_RSEQ
+	prev->rseq_sched_delay = 0;
+#endif
 #ifdef CONFIG_SCHED_DEBUG
 	rq->last_seen_need_resched_ns = 0;
 #endif
diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
index 3919f03fde57..f2ce1040b737 100644
--- a/kernel/sched/syscalls.c
+++ b/kernel/sched/syscalls.c
@@ -1378,6 +1378,11 @@ static void do_sched_yield(void)
  */
 SYSCALL_DEFINE0(sched_yield)
 {
+	if (current->rseq_sched_delay) {
+		schedule();
+		return 0;
+	}
+
 	do_sched_yield();
 	return 0;
 }
-- 
2.43.5

[PATCH 2/2] Sched: Add scheduler stat for cpu time slice extension

[Prakash Sangappa]

Add scheduler stat to record number of times the thread was granted
cpu time slice extension.

Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
---
 include/linux/sched.h | 2 ++
 kernel/rseq.c         | 1 +
 kernel/sched/core.c   | 5 +++++
 kernel/sched/debug.c  | 1 +
 4 files changed, 9 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 75abe260de72..927d54b665e6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -327,6 +327,7 @@ extern void io_schedule_finish(int token);
 extern long io_schedule_timeout(long timeout);
 extern void io_schedule(void);
 extern void hrtick_local_start(u64 delay);
+extern void update_stat_preempt_delayed(struct task_struct *t);
 
 /**
  * struct prev_cputime - snapshot of system and user cputime
@@ -538,6 +539,7 @@ struct sched_statistics {
 	u64				nr_wakeups_affine_attempts;
 	u64				nr_wakeups_passive;
 	u64				nr_wakeups_idle;
+	u64				nr_preempt_delay_granted;
 
 #ifdef CONFIG_SCHED_CORE
 	u64				core_forceidle_sum;
diff --git a/kernel/rseq.c b/kernel/rseq.c
index 9f83d47253ce..230cb84036b1 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -451,6 +451,7 @@ bool rseq_delay_resched(void)
 		return false;
 
 	t->rseq_sched_delay = 1;
+	update_stat_preempt_delayed(t);
 
 	return true;
 }
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index cee50e139723..034c76f0514c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -924,6 +924,11 @@ void hrtick_local_start(u64 delay)
 	rq_unlock(rq, &rf);
 }
 
+void update_stat_preempt_delayed(struct task_struct *t)
+{
+	schedstat_inc(t->stats.nr_preempt_delay_granted);
+}
+
 static void hrtick_rq_init(struct rq *rq)
 {
 #ifdef CONFIG_SMP
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index ef047add7f9e..e160e14b348f 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -1213,6 +1213,7 @@ void proc_sched_show_task(struct task_struct *p, struct pid_namespace *ns,
 		P_SCHEDSTAT(nr_wakeups_affine_attempts);
 		P_SCHEDSTAT(nr_wakeups_passive);
 		P_SCHEDSTAT(nr_wakeups_idle);
+		P_SCHEDSTAT(nr_preempt_delay_granted);
 
 		avg_atom = p->se.sum_exec_runtime;
 		if (nr_switches)
-- 
2.43.5

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

[kernel test robot]

Hi Prakash,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/sched/core]
[also build test ERROR on peterz-queue/sched/core linus/master v6.14-rc2 next-20250214]
[cannot apply to tip/core/entry]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Prakash-Sangappa/Sched-Scheduler-time-slice-extension/20250215-090421
base:   tip/sched/core
patch link:    https://lore.kernel.org/r/20250215005414.224409-2-prakash.sangappa%40oracle.com
patch subject: [PATCH 1/2] Sched: Scheduler time slice extension
config: hexagon-allnoconfig (https://download.01.org/0day-ci/archive/20250216/202502160310.ZHjm28qH-lkp@intel.com/config)
compiler: clang version 21.0.0git (https://github.com/llvm/llvm-project 910be4ff90d7d07bd4518ea03b85c0974672bf9c)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250216/202502160310.ZHjm28qH-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202502160310.ZHjm28qH-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from kernel/sched/build_policy.c:66:
>> kernel/sched/syscalls.c:1372:15: error: no member named 'rseq_sched_delay' in 'struct task_struct'
    1372 |         if (current->rseq_sched_delay) {
         |             ~~~~~~~  ^
   1 error generated.


vim +1372 kernel/sched/syscalls.c

  1361	
  1362	/**
  1363	 * sys_sched_yield - yield the current processor to other threads.
  1364	 *
  1365	 * This function yields the current CPU to other tasks. If there are no
  1366	 * other threads running on this CPU then this function will return.
  1367	 *
  1368	 * Return: 0.
  1369	 */
  1370	SYSCALL_DEFINE0(sched_yield)
  1371	{
> 1372		if (current->rseq_sched_delay) {
  1373			schedule();
  1374			return 0;
  1375		}
  1376	
  1377		do_sched_yield();
  1378		return 0;
  1379	}
  1380	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[kernel test robot]

Hi Prakash,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/sched/core]
[also build test ERROR on peterz-queue/sched/core linus/master v6.14-rc2 next-20250214]
[cannot apply to tip/core/entry]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Prakash-Sangappa/Sched-Scheduler-time-slice-extension/20250215-090421
base:   tip/sched/core
patch link:    https://lore.kernel.org/r/20250215005414.224409-2-prakash.sangappa%40oracle.com
patch subject: [PATCH 1/2] Sched: Scheduler time slice extension
config: alpha-allnoconfig (https://download.01.org/0day-ci/archive/20250216/202502160412.H5MjYC21-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250216/202502160412.H5MjYC21-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202502160412.H5MjYC21-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from kernel/sched/build_policy.c:66:
   kernel/sched/syscalls.c: In function 'sys_sched_yield':
>> kernel/sched/syscalls.c:1372:20: error: 'struct task_struct' has no member named 'rseq_sched_delay'
    1372 |         if (current->rseq_sched_delay) {
         |                    ^~


vim +1372 kernel/sched/syscalls.c

  1361	
  1362	/**
  1363	 * sys_sched_yield - yield the current processor to other threads.
  1364	 *
  1365	 * This function yields the current CPU to other tasks. If there are no
  1366	 * other threads running on this CPU then this function will return.
  1367	 *
  1368	 * Return: 0.
  1369	 */
  1370	SYSCALL_DEFINE0(sched_yield)
  1371	{
> 1372		if (current->rseq_sched_delay) {
  1373			schedule();
  1374			return 0;
  1375		}
  1376	
  1377		do_sched_yield();
  1378		return 0;
  1379	}
  1380	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 0/2] Scheduler time extension

[Steven Rostedt]

On Sat, 15 Feb 2025 00:54:12 +0000
Prakash Sangappa <prakash.sangappa@oracle.com> wrote:

> Follow up to discussion in [1], posting these patches.
> They are based on use of the restartable sequences(rseq) for API.
> 
> However, currently the discussion is on thread [2] in response to patch
> posted by Steven. Mainly about whether this feature should be applicable
> only to normal threads(SCHED_OTHER) under PREEMPT_LAZY preemption model
> or keep it independent of the preemption method.
> 
> [1] https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com/
> [2] https://lore.kernel.org/all/20250131225837.972218232@goodmis.org/

I'm still 100% against this delaying any non SCHED_OTHER task.

-- Steve

Re: [PATCH 0/2] Scheduler time extension

[Prakash Sangappa]

> On Feb 17, 2025, at 9:00 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Sat, 15 Feb 2025 00:54:12 +0000
> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
> 
>> Follow up to discussion in [1], posting these patches.
>> They are based on use of the restartable sequences(rseq) for API.
>> 
>> However, currently the discussion is on thread [2] in response to patch
>> posted by Steven. Mainly about whether this feature should be applicable
>> only to normal threads(SCHED_OTHER) under PREEMPT_LAZY preemption model
>> or keep it independent of the preemption method.
>> 
>> [1] https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com/
>> [2] https://lore.kernel.org/all/20250131225837.972218232@goodmis.org/
> 
> I'm still 100% against this delaying any non SCHED_OTHER task.

How do we proceed on this feature? 
Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?

-Prakash


> 
> -- Steve

Re: [PATCH 0/2] Scheduler time extension

[Steven Rostedt]

On Tue, 18 Mar 2025 16:10:09 +0000
Prakash Sangappa <prakash.sangappa@oracle.com> wrote:

> How do we proceed on this feature? 
> Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?

The merge window is about to open and I'm way behind in what needs to go in.

Let's continue this discussion after rc1 comes out.

-- Steve

Re: [PATCH 0/2] Scheduler time extension

[Prakash Sangappa]

> On Mar 22, 2025, at 3:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Tue, 18 Mar 2025 16:10:09 +0000
> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
> 
>> How do we proceed on this feature? 
>> Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?
> 
> The merge window is about to open and I'm way behind in what needs to go in.
> 
> Let's continue this discussion after rc1 comes out.

Can the API be finalized? We have an use case which will benefit from it. So like to see this feature
merged. 

-Prakash.

> 
> -- Steve

Re: [PATCH 0/2] Scheduler time extension

[Steven Rostedt]

On Fri, 11 Apr 2025 20:54:14 +0000
Prakash Sangappa <prakash.sangappa@oracle.com> wrote:

> > On Mar 22, 2025, at 3:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > On Tue, 18 Mar 2025 16:10:09 +0000
> > Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
> >   
> >> How do we proceed on this feature? 
> >> Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?  
> > 
> > The merge window is about to open and I'm way behind in what needs to go in.
> > 
> > Let's continue this discussion after rc1 comes out.  
> 
> Can the API be finalized? We have an use case which will benefit from it. So like to see this feature
> merged. 

I'm still not for SCHED_OTHER tasks being allowed to delay RT or deadline
tasks, even for 5us. But if that's what Peter wants, I'm not going to nack
it.

Just keep it configurable so that it can be easily disabled, as I have no
intentions of using it.

-- Steve

Re: [PATCH 0/2] Scheduler time extension

[Prakash Sangappa]

Resending - as the previous email did not make it to the mailing list.

> On Apr 14, 2025, at 9:41 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Fri, 11 Apr 2025 20:54:14 +0000
> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
> 
>>> On Mar 22, 2025, at 3:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>> 
>>> On Tue, 18 Mar 2025 16:10:09 +0000
>>> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
>>> 
>>>> How do we proceed on this feature? 
>>>> Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?  
>>> 
>>> The merge window is about to open and I'm way behind in what needs to go in.
>>> 
>>> Let's continue this discussion after rc1 comes out.  
>> 
>> Can the API be finalized? We have an use case which will benefit from it. So like to see this feature
>> merged.
> 
> I'm still not for SCHED_OTHER tasks being allowed to delay RT or deadline
> tasks, even for 5us. But if that's what Peter wants, I'm not going to nack
> it.
> 
> Just keep it configurable so that it can be easily disabled, as I have no
> intentions of using it.
> 

Ok, could we add a CONFIG_ option to choose this feature or are you suggesting disabling with a tunable?
Also make the delay a tunable? Caped at 50us.

Will send out an updated patch.

-Prakash


> -- Steve

Re: [PATCH 0/2] Scheduler time extension

[Sebastian Andrzej Siewior]

On 2025-04-14 12:41:49 [-0400], Steven Rostedt wrote:
> On Fri, 11 Apr 2025 20:54:14 +0000
> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
> 
> > > On Mar 22, 2025, at 3:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > > 
> > > On Tue, 18 Mar 2025 16:10:09 +0000
> > > Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
> > >   
> > >> How do we proceed on this feature? 
> > >> Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?  
> > > 
> > > The merge window is about to open and I'm way behind in what needs to go in.
> > > 
> > > Let's continue this discussion after rc1 comes out.  
> > 
> > Can the API be finalized? We have an use case which will benefit from it. So like to see this feature
> > merged. 
> 
> I'm still not for SCHED_OTHER tasks being allowed to delay RT or deadline
> tasks, even for 5us. But if that's what Peter wants, I'm not going to nack
> it.

I tried to explain in
	https://lore.kernel.org/all/20250206150152.-5Fauhtm@linutronix.de

that I don't see how this delay could work for PREEMPT_RT.

> Just keep it configurable so that it can be easily disabled, as I have no
> intentions of using it.

same here.

> -- Steve

Sebastian

Re: [PATCH 0/2] Scheduler time extension

[Prakash Sangappa]

> On Apr 14, 2025, at 11:25 PM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> On 2025-04-14 12:41:49 [-0400], Steven Rostedt wrote:
>> On Fri, 11 Apr 2025 20:54:14 +0000
>> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
>> 
>>>> On Mar 22, 2025, at 3:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>>> 
>>>> On Tue, 18 Mar 2025 16:10:09 +0000
>>>> Prakash Sangappa <prakash.sangappa@oracle.com> wrote:
>>>> 
>>>>> How do we proceed on this feature? 
>>>>> Are we leaning towards enabling this feature for SCHED_OTHER only under PREEMPT_LAZY?  
>>>> 
>>>> The merge window is about to open and I'm way behind in what needs to go in.
>>>> 
>>>> Let's continue this discussion after rc1 comes out.  
>>> 
>>> Can the API be finalized? We have an use case which will benefit from it. So like to see this feature
>>> merged. 
>> 
>> I'm still not for SCHED_OTHER tasks being allowed to delay RT or deadline
>> tasks, even for 5us. But if that's what Peter wants, I'm not going to nack
>> it.
> 
> I tried to explain in
> https://lore.kernel.org/all/20250206150152.-5Fauhtm@linutronix.de
> 
> that I don't see how this delay could work for PREEMPT_RT.
> 
>> Just keep it configurable so that it can be easily disabled, as I have no
>> intentions of using it.
> 
> same here.

Posted a V2 patch.
https://lore.kernel.org/all/20250418193410.2010058-1-prakash.sangappa@oracle.com/

Prakash

> 
>> -- Steve
> 
> Sebastian