[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190322174334.GC69236@devbig004.ftw2.facebook.com>
Date: Fri, 22 Mar 2019 10:43:34 -0700
From: Tejun Heo <tj@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
Lai Jiangshan <jiangshanlai@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/2] workqueue: Use normal rcu
Hello,
On Thu, Mar 21, 2019 at 09:59:35PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-03-13 17:55:47 [+0100], To linux-kernel@...r.kernel.org wrote:
> > From: Thomas Gleixner <tglx@...utronix.de>
> >
> > There is no need for sched_rcu. The undocumented reason why sched_rcu
> > is used is to avoid a few explicit rcu_read_lock()/unlock() pairs by
> > the fact that sched_rcu reader side critical sections are also protected
> > by preempt or irq disabled regions.
> >
> > Replace rcu_read_lock_sched with rcu_read_lock and acquire the RCU lock
> > where it is not yet explicit acquired. Replace local_irq_disable() with
> > rcu_read_lock(). Update asserts.
> >
> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> > [bigeasy: mangle changelog a little]
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>
> A gentle ping.
We can switch but it doesn't really say why we'd want to. Can you
please explain why this is better?
Thanks.
--
tejun
Powered by blists - more mailing lists