From: Gleb Natapov <gleb@redhat.com>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
linux-next list <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
paulmck@linux.vnet.ibm.com, sasha.levin@oracle.com,
avi@redhat.com
Subject: Re: [RFC PATCH v2] Add rcu user eqs exception hooks for async page fault
Date: Fri, 30 Nov 2012 12:08:18 +0200 [thread overview]
Message-ID: <20121130100818.GE20873@redhat.com> (raw)
In-Reply-To: <1354264606.2552.39.camel@ThinkPad-T5421.cn.ibm.com>
On Fri, Nov 30, 2012 at 04:36:46PM +0800, Li Zhong wrote:
> On Thu, 2012-11-29 at 19:25 +0200, Gleb Natapov wrote:
> > On Thu, Nov 29, 2012 at 03:40:05PM +0100, Frederic Weisbecker wrote:
> > > 2012/11/29 Li Zhong <zhong@linux.vnet.ibm.com>:
> > > > On Wed, 2012-11-28 at 13:55 +0100, Frederic Weisbecker wrote:
> > > >> > With rcu_user_exit() at the beginning, now rcu_irq_enter() only protects
> > > >> > the cpu idle eqs, but it's not good to call rcu_irq_exit() after the cpu
> > > >> > halt and the page ready.
> > > >>
> > > >> Hmm, why is it not good?
> > > >
> > > > I think in this case, as cpu halts and waits for page ready, it is
> > > > really in idle, and it's better for rcu to think it as rcu idle. But
> > > > with rcu_irq_enter(), the rcu would not think this cpu as idle. And the
> > > > rcu_irq_exit() is only called after this idle period to mark this cpu as
> > > > rcu idle again.
> > >
> > >
> > > Indeed. How about calling rcu_irq_exit() before native_safe_halt() and
> > > rcu_irq_enter() right after?
> > >
> > We can't. If exception happens in the middle of rcu read section while
> > preemption is disabled then calling rcu_irq_exit() before halt is
> > incorrect. We can do that only if exception happen during idle and this
> > should be rare enough for us to not care.
>
> If I understand correctly, maybe it doesn't cause problems.
>
> I guess you mean in other(not idle) task's rcu read critical section, we
> get an async page fault? In this case the rcu_idle_exit() won't make
> this cpu to enter rcu idle state. As the task environment is rcu non
> idle. This is the case we use rcu_irq_enter()/rcu_irq_exit() in code
> path where it might be in rcu idle or rcu non idle, and they don't
> change the rcu non-idle state if used in rcu non-idle state.
>
> And it is also safe if it is rcu read critical section in idle, as it is
> most probably wrapped in an outer rcu_irq_enter/exit(), so we have
>
> rcu idle
> rcu_irq_enter() - exit rcu idle, to protect the read section
> exception
> rcu_irq_enter() in the page not present path
> rcu_irq_exit() before halt
>
Yes, I was thinking about this scenario and you are right, since
rcu_irq_enter() will be nested it should be safe to call rcu_irq_exit
before halt.
> so the halt is also safe here, as we have two rcu_irq_enter() and one
> rcu_irq_exit().
>
> I agree with Frederic that this is the safest and simplest way now, and
> will try to update the code according to it.
>
> Thanks, Zhong
>
> > > >> > So I still want to remove it. And later if it shows that we really needs
> > > >> > rcu somewhere in this code path, maybe we could use RCU_NONIDLE() to
> > > >> > protect it. ( The suspicious RCU usage reported in commit
> > > >> > c5e015d4949aa665 seems related to schedule(), which is not in the code
> > > >> > path if we are in cpu idle eqs )
> > > >>
> > > >> Yes but if rcu_irq_*() calls are fine to be called there, and I
> > > >> believe they are because exception_enter() exits the user mode, we
> > > >> should start to protect there right now instead of waiting for a
> > > >> potential future warning of illegal RCU use.
> > > >
> > > > I agree, but I think by only protecting the necessary code avoids
> > > > marking the entire waiting period as rcu non idle.
> > >
> > > If we use RCU_NONIDLE(), this assume we need to check all the code
> > > there deeply for potential RCU uses and ensure it will never be
> > > extended later to use RCU. We really don't scale enough for that.
> > > There are too much subsystems involved there: waitqueue, spinlocks,
> > > slab, per cpu, etc...
> > >
> > > So I strongly suggest we use rcu_irq_*() APIs, and relax them around
> > > native_safe_halt() like I suggested above. This seems to me the safest
> > > solution.
> >
> > --
> > Gleb.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
--
Gleb.
next prev parent reply other threads:[~2012-11-30 10:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 5:15 [RFC PATCH] Fix abnormal rcu dynticks_nesting values related to async page fault Li Zhong
2012-11-27 5:58 ` [PATCH rcu] use new nesting value for rcu_dyntick trace in rcu_eqs_enter_common Li Zhong
2012-11-27 15:18 ` Paul E. McKenney
2012-11-27 13:07 ` [RFC PATCH] Fix abnormal rcu dynticks_nesting values related to async page fault Gleb Natapov
2012-11-27 14:01 ` Sasha Levin
2012-11-27 15:25 ` Paul E. McKenney
2012-11-27 15:34 ` Frederic Weisbecker
2012-11-27 14:38 ` Frederic Weisbecker
2012-11-27 15:44 ` Gleb Natapov
2012-11-27 15:56 ` Frederic Weisbecker
2012-11-27 16:19 ` Paul E. McKenney
2012-11-27 16:48 ` Frederic Weisbecker
2012-11-27 16:59 ` Paul E. McKenney
2012-11-27 16:39 ` Gleb Natapov
2012-11-27 16:51 ` Frederic Weisbecker
2012-11-27 17:00 ` Gleb Natapov
2012-11-27 17:30 ` Frederic Weisbecker
2012-11-27 17:47 ` Gleb Natapov
2012-11-27 18:12 ` Frederic Weisbecker
2012-11-27 19:27 ` Gleb Natapov
2012-11-27 22:53 ` Frederic Weisbecker
2012-11-27 22:54 ` Frederic Weisbecker
2012-11-27 15:39 ` Frederic Weisbecker
2012-11-27 16:16 ` Paul E. McKenney
2012-11-27 16:31 ` Frederic Weisbecker
2012-11-27 16:29 ` Frederic Weisbecker
2012-11-28 8:18 ` [RFC PATCH v2] Add rcu user eqs exception hooks for " Li Zhong
2012-11-28 12:55 ` Frederic Weisbecker
2012-11-28 13:53 ` Gleb Natapov
2012-11-28 14:25 ` Frederic Weisbecker
2012-11-29 11:07 ` Gleb Natapov
2012-11-29 14:47 ` Frederic Weisbecker
2012-11-30 9:18 ` [RFC PATCH v3] " Li Zhong
2012-11-30 10:26 ` Gleb Natapov
2012-12-03 2:08 ` Li Zhong
2012-12-03 8:30 ` Gleb Natapov
2012-12-03 9:57 ` Gleb Natapov
2012-12-04 2:35 ` [ PATCH] " Li Zhong
2012-12-18 13:25 ` Gleb Natapov
2012-12-04 2:36 ` [RFC PATCH v3] " Li Zhong
2012-12-04 5:11 ` Gleb Natapov
2012-12-04 5:40 ` Li Zhong
2012-12-04 13:02 ` Gleb Natapov
2012-12-04 14:28 ` Paul E. McKenney
2012-11-29 1:49 ` [RFC PATCH v2] " Li Zhong
2012-11-29 14:40 ` Frederic Weisbecker
2012-11-29 17:25 ` Gleb Natapov
2012-11-30 8:36 ` Li Zhong
2012-11-30 10:08 ` Gleb Natapov [this message]
2012-11-27 16:43 ` [RFC PATCH] Fix abnormal rcu dynticks_nesting values related to " Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121130100818.GE20873@redhat.com \
--to=gleb@redhat.com \
--cc=avi@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sasha.levin@oracle.com \
--cc=zhong@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).