"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> writes:
> On Mon, Dec 18, 2017 at 03:41:41PM +0800, Huang, Ying wrote:
>> "Huang, Ying" <ying.huang@xxxxxxxxx> writes:
>> And, it appears that if we replace smp_wmb() in _enable_swap_info() with
>> stop_machine() in some way, we can avoid smp_rmb() in get_swap_device().
>> This can reduce overhead in normal path further. Can we get same effect
>> with RCU? For example, use synchronize_rcu() instead of stop_machine()?
>>
>> Hi, Paul, can you help me on this?
>
> If the key loads before and after the smp_rmb() are within the same
> RCU read-side critical section, -and- if one of the critical writes is
> before the synchronize_rcu() and the other critical write is after the
> synchronize_rcu(), then you normally don't need the smp_rmb().
>
> Otherwise, you likely do still need the smp_rmb().
My question may be too general, let make it more specific. For the
following program,
"
int a;
int b;
void intialize(void)
{
a = 1;
synchronize_rcu();
b = 2;
}
void test(void)
{
int c;
rcu_read_lock();
c = b;
/* ignored smp_rmb() */
if (c)
pr_info("a=%d\n", a);
rcu_read_unlock();
}
"
Is it possible for it to show
"
a=0
"
in kernel log?
If it couldn't, this could be a useful usage model of RCU to accelerate
hot path.
Best Regards,
Huang, Ying
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
