On Tue, Feb 4, 2025 at 10:03 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Tue, 4 Feb 2025 19:56:09 -0500 > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > > > Here is the RFC I had sent that Peter is referring > > > > FWIW, I second the idea of a new syscall for this than (ab)using rseq > > and also independence from preemption method. I agree that something > > generic is better than relying on preemption method. > > So you are for adding another user/kernel memory mapped section? I don't personally mind that. > And you are also OK with allowing any task to make an RT task wait longer? > > Putting my RT hat back on, I would definitely disable that on any system > that requires RT. Just so I understand, you are basically saying that you want this feature only for FAIR tasks, and allowing RT tasks to extend time slice might actually hurt the latency of (other) RT tasks on the system right? This assumes PREEMPT_RT because the latency is 50us right? But in a poorly designed system, if you have RT tasks at higher priority that preempt things lower in RT, that would already cause latency anyway. Similarly, I would also consider any PREEMPT_RT system that (mis)uses this API in an RT task as also a poorly designed system. I think PREEMPT_RT systems generally require careful design anyway. So the fact that a system is poorly designed and thus causes latency is not the kernel's problem IMO. In any case, if you want this to only work on FAIR tasks and not RT tasks, why is that only possible to do with rseq() + LAZY preemption and not Prakash's new API + all preemption modes? Also you can just ignore RT tasks (not that I'm saying that's a good idea but..) in taskshrd_delay_resched() in that patch if you ever wanted to do that. I just feel the RT latency thing is a non-issue AFAICS. thanks, - Joel
