Messages in this thread | | | Date | Thu, 9 Nov 2023 18:41:51 -0500 | From | Steven Rostedt <> | Subject | Re: [RFC PATCH 85/86] treewide: drivers: remove cond_resched() |
| |
On Thu, 9 Nov 2023 15:25:54 -0800 Dmitry Torokhov <dmitry.torokhov@gmail.com> 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
| |