Messages in this thread | | | Date | Tue, 26 Jul 2022 07:30:22 -1000 | From | Tejun Heo <> | Subject | Re: [RFC PATCH] workqueue: Unbind workers before sending them to exit() |
| |
Hello,
On Mon, Jul 25, 2022 at 11:21:37AM +0100, Valentin Schneider wrote: > On 22/07/22 19:16, Tejun Heo wrote: > > On Thu, Jul 21, 2022 at 02:53:43PM +0100, Valentin Schneider wrote: > >> > I think it needs something like task_set_cpumask_possible() which is > >> > documented as being usable in (raw) spinlocks and set the task's cpumask > >> > to cpu_possible_mask and let the later ttwu help migrate it to a > >> > proper non-isolated CPU or let it keep running. > >> > >> I'll see what I can come up with, thanks for the suggestion. > > > > Alternatively, we can just kill all the idle kworkers on isolated cpus at > > the end of the booting process. > > Hm so my choice of words in the changelog wasn't great - "initial setup" > can be kernel init, but *also* setup of whatever workload is being deployed > onto the system. > > So you can be having "normal" background activity (I've seen some IRQs end > up with schedule_work() on isolated CPUs, they're not moved away at boot > time but rather shortly before launching the latency-sensitive app), some > preliminary stats collection / setup to make sure the CPU will be quiet > (e.g. refresh_vm_stats()), and *then* the application starts with > fresh-but-no-longer-required extra pcpu kworkers assigned to its CPU.
Ah, I see. I guess we'll need to figure out how to unbind the workers then.
Thanks.
-- tejun
| |