> On Feb 5, 2025, at 5:16 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > 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? > The new syscall/API proposed was to provide per thread shared mapped area(shared structure) that are allocated from memory pages that are pinned. So the kernel could access it without the need for a copyin/copyout. The idea is that it would be helpful in places where we cannot take a page fault in the kernel codepath. >> >>> 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
