On Fri, Feb 19, 2021 at 11:45:39AM -0800, Paul E. McKenney wrote: > On Fri, Feb 19, 2021 at 02:14:29PM -0500, Steven Rostedt wrote: > > On Fri, 19 Feb 2021 10:18:11 -0800 > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > > > We can further prevent entry into dyntick-idle state until > > > the ksoftirqd kthreads have been spawned, which means that if softirq > > > handlers must be deferred, they will be resumed within one jiffy by the > > > next scheduler-clock interrupt. > > > > Why not just prevent entry into dyntick-idle state until the system is > > finished booting? As you said; There should be no latency-sensitive > > applications running, until after we started the system. > > Exactly, and that is the effect of patch to rcu_needs_cpu() that I just > now posted. > > Ah, your point is that if the tick keeps running, there is no need to > modify softirq? Good point, and I will test that, thank you!!! But sadly keeping the tick on without also modifying softirq still results in a hang. The problem is that when the kernel is booted with threadirqs=1, invoke_softirq() will avoid ever running the softirq handlers on the backside of an interrupt. So is this where Sebastian tells me that some -rt transformation can result in locking-based deadlocks if softirq handlers are ever run on the backside of an interrupt? ;-) Thanx, Paul
