On Wed, 5 Feb 2025 08:10:19 -0500 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > The preemption method will influence that decision, but user space doesn't > need to be know. If your issue is that this depends on the preemption method, I have a slight change to make it work for all preemption methods. I just replied to Joel about this: https://lore.kernel.org/all/20250205083857.3cc06aa7@xxxxxxxxxxxxxxxxxx/ I'll repeat some of it here. Currently we have: TYPE | Sched Tick | RT Wakeup | ===========+=======================+======================+ None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY | -----------+-----------------------+----------------------+ Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------+----------------------+ Full | NEED_RESCHED | NEED_RESCHED | -----------+-----------------------+----------------------+ Now, if we set NEED_RESCHED_LAZY in PREEMPT_FULL (and PREEMPT_RT) on a scheduler tick if it interrupted user space (not the kernel) then we have this: TYPE | Sched Tick | RT Wakeup | ===========+===================================+======================+ None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY | -----------+-----------------------------------+----------------------+ Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------------------+----------------------+ Full | NEED_RESCHED or NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------------------+----------------------+ Then going back to user space from the interrupt, we can use rseq and the LAZY bit to know if we should extend the tick or not! Even without rseq, this would behave the same as NEED_RESCHED_LAZY will schedule just like NEED_RESCHED when going back to user space. This will allow this schedule tick extension to work in all the preemption methods. Would this be something you are more OK with? I can go and test this out. -- Steve
