On Thu, 9 Nov 2023 15:25:54 -0800 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > Hi Anhur, > > On Tue, Nov 07, 2023 at 03:08:21PM -0800, Ankur Arora wrote: > > There are broadly three sets of uses of cond_resched(): > > > > 1. Calls to cond_resched() out of the goodness of our heart, > > otherwise known as avoiding lockup splats. > > ... > > What about RCU stalls? The calls to cond_resched() in evdev.c and > mousedev.c were added specifically to allow RCU to run in cases when > userspace passes a large buffer and the kernel is not fully preemptable. > First, this patch is being sent out premature as it depends on acceptance of the previous patches. When the previous patches are finished, then we don't need cond_resched() to protect against RCU stalls, because even "PREEMPT_NONE" will allow preemption inside the kernel. What the earlier patches do is introduce a concept of NEED_RESCHED_LAZY. Then when the scheduler wants to resched the task, it will set that bit instead of NEED_RESCHED (for the old PREEMPT_NONE version). For VOLUNTARY, it sets the LAZY bit of SCHED_OTHER but NEED_RESCHED for RT/DL tasks. For PREEMPT, it will always set NEED_RESCHED. NEED_RESCHED will always schedule, but NEED_RESCHED_LAZY only schedules when going to user space. Now after on tick (depending on HZ it can be 1ms, 3.3ms, 4ms 10ms) if NEED_RESCHED_LAZY is set, then it will set NEED_RESCHED, forcing a preemption at the next available moment (when preempt count is zero). This will be done even with the old PREEMPT_NONE configuration. That way we will no longer play whack-a-mole to get rid of all he long running kernel paths by inserting cond_resched() in them. -- Steve
