On Tue, 4 Feb 2025 16:30:53 +0100 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > If you go back and reread that initial thread, you'll find the 50us is > below the scheduling latency that random test box already had. > > I'm sure more modern systems will have a lower number, and slower > systems will have a larger number, but we got to pick a number :/ > > I'm fine with making it 20us. Or whatever. Its just a stupid number. > > But yes. If we're going to be doing this, there is absolutely no reason > not to allow DEADLINE/FIFO threads the same. Misbehaving FIFO is already > a problem, and we can make DL-CBS enforcement punch through it if we > have to. > > And less retries on the RSEQ for FIFO can equally improve performance. > > There is no difference between a 'malicious/broken' userspace consuming > the entire window in userspace (50us, 20us whatever it will be) and > doing a system call which we know will cause similar delays because it > does in-kernel locking. This is where we will disagree for the reasons I explained in my second email. This feature affects other tasks. And no, making it 20us doesn't make it better. Because from what I get from you, if we implement this, it will be available for all preemption methods (including PREEMPT_RT), where we do have less than 50us latency, and and even a 20us will break those applications. This was supposed to be only a hint to the kernel, not a complete feature that is hard coded and will override how other tasks behave. As system calls themselves can make how things are scheduled depending on the preemption method, I didn't want to add something that will change how things are scheduled that ignores the preemption method that was chosen. -- Steve
