On 2025-02-06 14:57:44 [+0100], Peter Zijlstra wrote: > On Thu, Feb 06, 2025 at 02:53:53PM +0100, Sebastian Andrzej Siewior wrote: > > On 2025-02-06 14:48:59 [+0100], Peter Zijlstra wrote: > > > On Thu, Feb 06, 2025 at 02:44:08PM +0100, Sebastian Andrzej Siewior wrote: > > > > SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of > > > > SCHED_FIFO/ RR/ DL because of this LAZY hint. > > > > > > Thing will get delayed if interrupts are disabled or kernel has > > > preemption disabled too. So as long as we ensure hint crap is of equal > > > order, nothing cares if you do. > > > > > > If you can't tell the difference between task does hint crap in > > > userspace and task is in the middle of syscall, you can't tell the > > > difference. > > > > I can tell the difference if I see a trace where an interrupt fires, > > performs a wakeup and the SCHED_OTHER task remains on CPU while the task > > SCHED_FIFO task sits on the runqueue until a timer fires. > > Right, but so what? Same delay will happen if interrupt fires in the > middle of a preempt_disable() region. But I do see an interrupt and a wakeup in the middle of a preempt-disable section based on the preempt-counter. Then once the preempt-disabled section is done, sched-switch is expected. > Or if interrupt gets pending while interrupts are disabled, except your > trace will not show that. That is true. In general we try not to have a lot of these. Also pushing the "unexpected" part of the CPU such as unrelated interrupts. So may end up a RT thread and SCHED_OTHER threads on the same CPU. It would be very unfortunate if this "let me give a bit extra time so I get out of my critical section" within this SCHED_OTHER application affects the RT application. You run SCHED_OTHER tasks and a cyclic interrupt wakes your RT task every ms. You expect to be scheduled asap, so ideally 0us but 70us in real world. Then this feature adds 20us on top? > Your worst case response time isn't affected. That's all that matters. Sebastian
