From: Steven Rostedt > Sent: 08 November 2023 19:42 > > On Wed, 8 Nov 2023 11:15:37 -0800 > Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > FOr the memcpy_kunit.c cases, I don't think there are preemption > > locations in its loops. Perhaps I'm misunderstanding something? Why will > > the memcpy test no longer produce softlockup splats? > > This patchset will switch over to a NEED_RESCHED_LAZY routine, so that > VOLUNTARY and NONE preemption models will be forced to preempt if its in > the kernel for too long. > > Time slice is over: set NEED_RESCHED_LAZY > > For VOLUNTARY and NONE, NEED_RESCHED_LAZY will not preempt the kernel (but > will preempt user space). > > If in the kernel for over 1 tick (1ms for 1000Hz, 4ms for 250Hz, etc), > if NEED_RESCHED_LAZY is still set after one tick, then set NEED_RESCHED. Delaying the reschedule that long seems like a regression. I'm sure a lot of the cond_resched() calls were added to cause pre-emption much earlier than 1 tick. I doubt the distibutions will change from VOLUTARY any time soon. So that is what most people will be using. David. > > NEED_RESCHED will now schedule in the kernel once it is able to regardless > of preemption model. (PREEMPT_NONE will now use preempt_disable()). > > This allows us to get rid of all cond_resched()s throughout the kernel as > this will be the new mechanism to keep from running inside the kernel for > too long. The watchdog is always longer than one tick. > > -- Steve - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
