Thread (50 messages) 50 messages, 5 authors, 2012-12-18

Re: [RFC PATCH v2] Add rcu user eqs exception hooks for async page fault

From: Gleb Natapov <hidden>
Date: 2012-11-29 17:25:49
Also in: lkml

On Thu, Nov 29, 2012 at 03:40:05PM +0100, Frederic Weisbecker wrote:
2012/11/29 Li Zhong [off-list ref]:
quoted
On Wed, 2012-11-28 at 13:55 +0100, Frederic Weisbecker wrote:
quoted
quoted
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.
quoted
quoted
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help