Messages in this thread | | | Date | Sat, 29 Jul 2023 18:07:12 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 1/2] workqueue: Introduce PF_WQ_RESCUE_WORKER |
| |
On Sat, Jul 29, 2023 at 02:53:33PM +0100, Aaron Tomlin wrote: > The Linux kernel does not provide a way to differentiate between a > kworker and a rescue kworker for user-mode. > From user-mode, one can establish if a task is a kworker by testing for > PF_WQ_WORKER in a specified task's flags bit mask (or bitmap) via > /proc/[PID]/stat. Indeed, one can examine /proc/[PID]/stack and search > for the function namely "rescuer_thread". This is only available to the > root user. > > It can be useful to identify a rescue kworker since their CPU affinity > cannot be modified and their initial CPU assignment can be safely ignored. > Furthermore, a workqueue that was created with WQ_MEM_RECLAIM and > WQ_SYSFS the cpumask file is not applicable to the rescue kworker. > By design a rescue kworker should run anywhere. > > This patch introduces PF_WQ_RESCUE_WORKER and ensures it is set and > cleared appropriately.
Is the implication that PF_flags are considered ABI? We've been changing them quite a bit over the years.
Also, while we have a few spare bits atm, we used to be nearly out for a while, and I just don't think this is sane usage of them. We don't use PF flags just for userspace.
| |