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(-)
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
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
> 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
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
> 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
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
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
> 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
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
© 2016 - 2025 Red Hat, Inc.