[lkml]   [2019]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Remove GP_REPLAY state from rcu_sync
On 10/04, Joel Fernandes wrote:
> On Fri, Oct 04, 2019 at 05:41:03PM +0200, Oleg Nesterov wrote:
> > On 10/04, Joel Fernandes (Google) wrote:
> > >
> > > Taking a step back, why did we intend to have
> > > to wait for a new GP if another rcu_sync_exit() comes while one is still
> > > in progress?
> >
> > To ensure that if another CPU sees rcu_sync_is_idle() (GP_IDLE) after you
> > do rcu_sync_exit(), then it must also see all memory changes you did before
> > rcu_sync_exit().
> Would this not be better implemented using memory barriers, than starting new
> grace periods just for memory ordering? A memory barrier is lighter than
> having to go through a grace period. So something like: if the state is
> already GP_EXIT, then rcu_sync_exit() issues a memory barrier instead of
> replaying. But if state is GP_PASSED, then wait for a grace period.

But these 2 cases do not differ. If we can use mb() if GP_EXIT, then we can
do the same if state == GP_PASSED and just move the state to GP_IDLE, and
remove both GP_PASSED/GP_REPLAY states.

However, in this case the readers will need the barrier too, and rcu_sync_enter()
will _always_ need to block (wait for GP).

rcu_sync.c is "equivalent" to the following implementation:

struct rcu_sync_struct {
atomic_t writers;

bool rcu_sync_is_idle(rss)
return atomic_read(rss->writers) == 0;

void rcu_sync_enter(rss)

void rcu_sync_exit(rss)


- rcu_sync_exit() never blocks

- synchronize_rcu/call_rci is called only if it is really needed.
In particular, if 2 writers come in a row the 2nd one will not
block in _enter().


 \ /
  Last update: 2019-10-07 16:10    [W:0.102 / U:2.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site