On Wed, 17 Feb 2021 10:17:38 -0800 "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > 1. Spawn ksoftirqd earlier. > > > > > > 2. Suppress attempts to awaken ksoftirqd before it exists, > > > forcing all ksoftirq execution on the back of interrupts. > > > > > > Uladzislau and I each produced patches for #1, and I produced a patch > > > for #2. > > > > > > The only other option I know of is to push the call to init_kprobes() > > > later in the boot sequence, perhaps to its original subsys_initcall(), > > > or maybe only as late as core_initcall(). I added Masami and Steve on > > > CC for their thoughts on this. > > > > > > Is there some other proper fix that I am missing? > > > > Oh, I missed that the synchronize_rcu_tasks() will be involved the kprobes > > in early stage. Does the problem only exist in the synchronize_rcu_tasks() > > instead of synchronize_rcu()? If so I can just stop optimizer in early stage > > because I just want to enable kprobes in early stage, but not optprobes. > > > > Does the following patch help? > > It does look to me like it would! I clearly should have asked you about > this a couple of months ago. ;-) > > The proof of the pudding would be whether the powerpc guys can apply > this to v5.10-rc7 and have their kernel come up without hanging at boot. Who could I ask for testing this patch, Uladzislau? I think the test machine which enough slow or the kernel has much initcall to run optimization thread while booting. In my environment, I could not reproduce that issue because the optimizer was sheduled after some tick passed. At that point, ksoftirqd has already been initialized. Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
