On Tue, Jan 21, 2020 at 06:45:32AM -0500, Qian Cai wrote: > > > > On Jan 21, 2020, at 12:09 AM, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > > > This is what you get when a grace period has been requested, but does > > not start within 21 seconds or so. The "->state: 0x1ffff" is a new one > > on me -- that normally happens only before RCU's grace-period kthread > > has been spawned. But by 97 seconds after boot, it should definitely > > already be up and running. > > > > Is the system responsive at this point? > > Yes, it works fine. > > > Except... Why is it taking 96 seconds for the system to get to the point > > where it prints "Dentry cache hash table entries:"? That happens at 0.139 > > seconds on my laptop. And at about the same time on a much larger system. > > > > I could easily imagine that all sorts of things would break when boot > > takes that long. > > I suppose the kernel has CONFIG_EFI_PGT_DUMP=y, so it takes a while to run just before rcu_check_gp_start_stall(). New one on me! One approach would be to boot with rcupdate.rcu_cpu_stall_timeout=300, which would allow more time. Longer term, I could suppress this warning during boot when CONFIG_EFI_PGT_DUMP=y, but that sounds quite specific. Alternatively, I could provide a Kconfig option that suppressed this during boot that was selected by whatever long-running boot-time Kconfig option needed it. Yet another approach would be for long-running operations like efi_dump_pagetable() to suppress stalls on entry and re-enable them upon exit. Thoughts? Thanx, Paul
