[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190320181210.GO4102@linux.ibm.com>
Date: Wed, 20 Mar 2019 11:12:10 -0700
From: "Paul E. McKenney" <paulmck@...ux.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Joel Fernandes <joel@...lfernandes.org>, tglx@...utronix.de,
Mike Galbraith <efault@....de>
Subject: Re: [PATCH v2] rcu: Allow to eliminate softirq processing from
rcutree
On Wed, Mar 20, 2019 at 06:59:52PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-03-20 10:30:01 [-0700], Paul E. McKenney wrote:
> > On Wed, Mar 20, 2019 at 05:35:32PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2019-03-20 09:15:00 [-0700], Paul E. McKenney wrote:
> > > > I am considering making it a module_param() to avoid namespace pollution,
> > > > as it would become something like rcutree.nosoftirq.
> > > >
> > > > Thoughts?
> > >
> > > nope, perfect.
> >
> > Please see below for an untested patch. Thoughts?
>
> > - if (rcu_softirq_enabled) {
> > + if (!nosoftirq) {
> > raise_softirq(RCU_SOFTIRQ);
> > } else {
>
> This double negation looks weird. Can we flip the logic somehow?
> /me testing if it works…
We could name it something like "use_softirq" and initialize it to true.
I am OK either way.
Thanx, Paul
Powered by blists - more mailing lists