[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210218083636.GA2030@pc638.lan>
Date: Thu, 18 Feb 2021 09:36:36 +0100
From: Uladzislau Rezki <urezki@...il.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: paulmck@...nel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Uladzislau Rezki <urezki@...il.com>,
LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
Michael Ellerman <mpe@...erman.id.au>,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Axtens <dja@...ens.net>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <neeraju@...eaurora.org>,
Joel Fernandes <joel@...lfernandes.org>,
Michal Hocko <mhocko@...e.com>,
"Theodore Y . Ts'o" <tytso@....edu>,
Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>,
rostedt@...dmis.org
Subject: Re: [PATCH 2/2] rcu-tasks: add RCU-tasks self tests
On Thu, Feb 18, 2021 at 02:03:07PM +0900, Masami Hiramatsu wrote:
> On Wed, 17 Feb 2021 10:17:38 -0800
> "Paul E. McKenney" <paulmck@...nel.org> 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.
>
>From my end i did some simulation and had a look at your change. So the
patch works on my setup. I see that optimization of kprobes is deferred
and can be initiated only from the subsys_initcall() phase. So the sequence
should be correct for v5.10-rc7:
1. ksoftirq is setup early_initcall();
2. rcu_spawn_tasks_* are setup in the core_initcall();
3. an optimization of kprobes are invoked from subsys_initcall().
For real test on power-pc you can ask Daniel Axtens <dja@...ens.net> for help.
--
Vlad Rezki
Powered by blists - more mailing lists