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. 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. 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. -- Josh
