> On May 9, 2022, at 1:09 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Mon, May 09, 2022 at 03:49:52PM -0400, Rik van Riel wrote: >> On Mon, 2022-05-09 at 12:17 -0700, Josh Poimboeuf wrote: >>> On Mon, May 09, 2022 at 03:10:16PM -0400, Rik van Riel wrote: >>> >>> >>>> Should kernel threads that can use a lot of CPU have >>>> something in their outer loop to transition KLPs, >>>> just like the idle task does? >>> >>> Maybe - I suppose this is the first time we've had an issue with >>> CPU-bound kthreads. I didn't know that was a thing ;-) >>> >> Kworkers have as much work as you want them to do, and with >> things like btrfs compression that can be quite a bit. > > To prevent patching, it would need to be some kind of sustained CPU > activity, rather than a burst. I guess we haven't seen that show up as > a real-world problem until now. Yes, we see this issue with sustained CPU activity from a kernel thread, which might be a bug itself. OTOH, the kernel thread does call cond_sched(), so it is not a deadlock. > > If you're able to identify which kthreads would be problematic, then > yeah, defining a "transition point" in their outer loops could be an > option. cond_sched() feels like a natural “transition point” to me, and it should solve many different variations of such problem. I agree that adding something to cond_sched() might be too much overhead for the system. So we are open for other suggestions. Thanks, Song > > We could look also at a more general approach, like stack checking from > an irq handler. But as Petr alluded to, that would be problematic for > CONFIG_FRAME_POINTER. > > We could maybe deprecate frame pointers on x86 for live patching, but I > think other arches would have a similar problem unless they were to do > something like the ORC unwinder.
