On Wed, 5 Feb 2025 00:09:51 -0500 Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > 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. I'm glad you don't personally mind it. Are you going to help maintain another memory mapped section? > > > 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? RT tasks don't have a time slice. They are affected by events. An external interrupt coming in, or a timer going off that states something is happening. Perhaps we could use this for SCHED_RR or maybe even SCHED_DEADLINE, as those do have time slices. But if it does get used, it should only be used when the task being scheduled is the same SCHED_RR priority, or if SCHED_DEADLINE will not fail its guarantees. > > 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 And that would be a poorly designed system, and not the problem of the kernel. > 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. Correct. And why I don't think this should be used for RT. It's SCHED_OTHER that doesn't have any control of the sched tick, where this hint can help. > > 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. Have you worked on any RT projects before? -- Steve
