Messages in this thread | | | Date | Fri, 20 Jan 2023 11:20:32 -0800 | From | "Paul E. McKenney" <> | Subject | Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test) |
| |
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
| |