Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test)

Paul E. McKenney
2023-01-20T19:20:38Z

On Fri, Jan 20, 2023 at 01:37:51PM -0500, Alan Stern wrote:
> On Fri, Jan 20, 2023 at 09:58:04AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 20, 2023 at 11:01:03AM -0500, Alan Stern wrote:
> > > On Wed, Jan 18, 2023 at 04:02:14PM -0800, Paul E. McKenney wrote:
> > > > There are pairs of per-CPU counters. One pair (->srcu_lock_count[])
> > > > counts the number of srcu_down_read() operations that took place on
> > > > that CPU and another pair (->srcu_unlock_count[]) counts the number
> > > > of srcu_down_read() operations that took place on that CPU. There is
> > > > an ->srcu_idx that selects which of the ->srcu_lock_count[] elements
> > > > should be incremented by srcu_down_read(). Of course, srcu_down_read()
> > > > returns the value of ->srcu_idx that it used so that the matching
> > > > srcu_up_read() will use that same index when incrementing its CPU's
> > > > ->srcu_unlock_count[].
> > > >
> > > > Grace periods go something like this:
> > > >
> > > > 1. Sum up the ->srcu_unlock_count[!ssp->srcu_idx] counters.
> > > >
> > > > 2. smp_mb().
> > > >
> > > > 3. Sum up the ->srcu_unlock_count[!ssp->srcu_idx] counters.
> > >
> > > Presumably you meant to write "lock" here, not "unlock".
> >
> > You are quite right, and apologies for my confusion.
> >
> > > > 4. If the sums are not equal, retry from #1.
> > > >
> > > > 5. smp_mb().
> > > >
> > > > 6. WRITE_ONCE(ssp->srcu_idx, !ssp->srcu_idx);
> > > >
> > > > 7. smp_mb().
> > > >
> > > > 8. Same loop as #1-4.
> > > >
> > > > So similar to r/w semaphores, but with two separate distributed counts.
> > > > This means that the number of readers need not go to zero at any given
> > > > point in time, consistent with the need to wait only on old readers.
> > >
> > > Reasoning from first principles, I deduce the following:
> > >
> > > You didn't describe exactly how srcu_down_read() and srcu_up_read()
> > > work. Evidently the unlock increment in srcu_up_read() should have
> > > release semantics, to prevent accesses from escaping out the end of the
> > > critical section. But the lock increment in srcu_down_read() has to be
> > > stronger than an acquire; to prevent accesses in the critical section
> > > escaping out the start, the increment has to be followed by smp_mb().
> >
> > You got it! There is some work going on to see if srcu_read_lock()'s
> > smp_mb() can be weakened to pure release, but we will see.
>
> That doesn't make sense. Release ordering in srcu_read_lock() would
> only prevent accesses from leaking _in_ to the critical section. It
> would do nothing to prevent accesses from leaking _out_.

Yes, I should have said srcu_read_unlock(). I do seem to be having
lock/unlock difficulties. :-/

We could remove the smp_mb() from srcu_read_lock(), but at the expense
of a round of IPIs from the grace-period code, along with interactions
with things like the CPU-hotplug code paths. I am not proposing
doing that, for one thing, one of the attractions of SRCU is its fast
and disturbance-free grace period when there are no readers in flight.
It is possible, though: Tasks Trace RCU does just this, IPIs, CPU hotplug,
and all.

There are other ways to do this, but the ones I know of would restrict
the contexts in which srcu_read_lock() and srcu_read_unlock() can be
executed, for example, in the context of offline CPUs.

> > > The smp_mb() fences in steps 5 and 7 appear to be completely
> > > unnecessary.
> >
> > For correctness, agreed. Their purpose is instead forward progress.
>
> It's hard to say whether they would be effective at that. smp_mb()
> forces the processor to wait until some time when previous writes have
> become visible to all CPUs. But if you don't wait for that potentially
> excessively long delay, you may be able to continue and be lucky enough
> to find that all previous writes have already become visible to all the
> CPUs that matter.
>
> As far as I know, smp_mb() doesn't expedite the process of making
> previous writes visible. However, I am very far from being an expert
> on system architecture design.

As you noticed, without the step-7 smp_mb(), a potentially large number
of invocations of srcu_read_lock() could use the old index value, that
is, the inces value that is to be counted in step 8. Then the step-8
phase of the grace period could unncessarily wait on those readers.

Similarly, without the step-5 smp_mb() and without the control
dependencies extending from the loads feeding into step 4's sum,
srcu_read_lock() and srcu_read_unlock() on other CPUs might prematurely
use the new index, which could force the step 1-4 phase of the grace
period to unnecessarily wait on those readers.

> > One can argue that step 5 is redundant due to control dependency, but
> > control dependencies are fragile, and as you say below, this code is
> > nowhere near a fastpath.
>
> Also, control dependencies do not contribute to forward progress.

I might be mistaken, and you can argue that the risk is small, but without
that ordering, step 4 could see unintended increments that could force
unnecessary retries of steps 1-3.

> > > Provided an smp_mb() is added at the very start and end of the grace
> > > period, the memory barrier in step 2 and its copy in step 8 can be
> > > demoted to smp_rmb().
> >
> > This might need to be smp_mb() to allow srcu_read_unlock() to be
> > demoted to release ordering. Work in progress.
>
> I thought srcu_read_unlock() already _is_ a release operation. The
> smp_mb() fence mentioned earlier needs to be in srcu_read_lock(), not
> unlock(). And there's no way that one can be demoted.

Agreed, my mistake earlier. The smp_mb() in srcu_read_lock() must
remaain smp_mb().

> srcu_read_unlock() does not need a full smp_mb().

That is quite possible, and that is what we are looking into. And testing
thus far agrees with you. But the grace-period ordering constraints
are quite severe, so this requires careful checking and severe testing.

> > > These changes would be small optimizations at best, and you may consider
> > > them unimportant in view of the fact that grace periods often last quite
> > > a long time.
> >
> > Agreed, keeping it simple and obvious is important on this code, which
> > is nowhere near a fastpath. The case of srcu_read_unlock() is another
> > thing altogether.
>
> Unfortunately, the full fence in srcu_read_lock() is unavoidable without
> very major changes to the algorithm -- probably a complete redesign.
> Without it, a read inside the critical section could be executed before
> the store part of the increment, which could lead synchronize_srcu() to
> believe that the critical section had not yet started when in fact it
> had.

I actually did type "srcu_read_unlock()" correctly in this case. ;-)

But yes, removing the smp_mb() from srcu_read_lock() is not in the cards.
On the other hand, doing so for srcu_read_unlock() just might be both
doable and worthwhile.

Thanx, Paul