RCU tests for Maple Tree

RCU tests for Maple Tree

[Paul E. McKenney]

Hello, Liam!

Apologies for my being so slow here, but just wanted to double-check my
understanding of this code.

There appear to be two tests that execute from run_check_rcu():

o	rcu_loop().  This appears to have RCU readers scanning the tree
	while an updater is adding a single range.  (Or replacing it,
	as the case might be.)

o	rcu_val().  This appears to have RCU readers repeatedly reading a
	given value while an updater is adding/replacing a single range.
	The test complains if no one sees the new value.

These tests appear to be the only use of threads, though perhaps the
test harness has some way of creating threads that I missed.

Are there other tests that I should be looking for?

							Thanx, Paul

Re: RCU tests for Maple Tree

[Liam Howlett]

* Paul E. McKenney <paulmck@kernel.org> [210517 11:40]:
> Hello, Liam!
> 
> Apologies for my being so slow here, but just wanted to double-check my
> understanding of this code.
> 
> There appear to be two tests that execute from run_check_rcu():
> 
> o	rcu_loop().  This appears to have RCU readers scanning the tree
> 	while an updater is adding a single range.  (Or replacing it,
> 	as the case might be.)
> 
> o	rcu_val().  This appears to have RCU readers repeatedly reading a
> 	given value while an updater is adding/replacing a single range.
> 	The test complains if no one sees the new value.
> 
> These tests appear to be the only use of threads, though perhaps the
> test harness has some way of creating threads that I missed.
> 
> Are there other tests that I should be looking for?

No, those are the only ones I'm running with threads right now.  I think
all RCU tests are run from check_rcu() iirc.  This did yield results of
failures that had to be addressed so I'm somewhat confident that it's
actually working.

From your wording I'm gathering I need to increase this by a lot more
test cases?

Thanks,
Liam

Re: RCU tests for Maple Tree

[Paul E. McKenney]

On Mon, May 17, 2021 at 04:30:53PM +0000, Liam Howlett wrote:
> * Paul E. McKenney <paulmck@kernel.org> [210517 11:40]:
> > Hello, Liam!
> > 
> > Apologies for my being so slow here, but just wanted to double-check my
> > understanding of this code.
> > 
> > There appear to be two tests that execute from run_check_rcu():
> > 
> > o	rcu_loop().  This appears to have RCU readers scanning the tree
> > 	while an updater is adding a single range.  (Or replacing it,
> > 	as the case might be.)
> > 
> > o	rcu_val().  This appears to have RCU readers repeatedly reading a
> > 	given value while an updater is adding/replacing a single range.
> > 	The test complains if no one sees the new value.
> > 
> > These tests appear to be the only use of threads, though perhaps the
> > test harness has some way of creating threads that I missed.
> > 
> > Are there other tests that I should be looking for?
> 
> No, those are the only ones I'm running with threads right now.  I think
> all RCU tests are run from check_rcu() iirc.  This did yield results of
> failures that had to be addressed so I'm somewhat confident that it's
> actually working.

OK, I guess I can feel relieved that I can still read code.  ;-)

> >From your wording I'm gathering I need to increase this by a lot more
> test cases?

I would feel better with the addition of something that looked more
like a stress test.  For but one example, is there some combination
of several successive update operations that can mess up slow readers
(that is, readers that are interrupted or preempted, and thus have
multiple updates happen while they are traversing the tree)?  If so,
the current tests will not find it.

							Thanx, Paul

Re: RCU tests for Maple Tree

[Paul E. McKenney]

On Mon, May 17, 2021 at 09:50:04AM -0700, Paul E. McKenney wrote:
> On Mon, May 17, 2021 at 04:30:53PM +0000, Liam Howlett wrote:
> > * Paul E. McKenney <paulmck@kernel.org> [210517 11:40]:
> > > Hello, Liam!
> > > 
> > > Apologies for my being so slow here, but just wanted to double-check my
> > > understanding of this code.
> > > 
> > > There appear to be two tests that execute from run_check_rcu():
> > > 
> > > o	rcu_loop().  This appears to have RCU readers scanning the tree
> > > 	while an updater is adding a single range.  (Or replacing it,
> > > 	as the case might be.)
> > > 
> > > o	rcu_val().  This appears to have RCU readers repeatedly reading a
> > > 	given value while an updater is adding/replacing a single range.
> > > 	The test complains if no one sees the new value.
> > > 
> > > These tests appear to be the only use of threads, though perhaps the
> > > test harness has some way of creating threads that I missed.
> > > 
> > > Are there other tests that I should be looking for?
> > 
> > No, those are the only ones I'm running with threads right now.  I think
> > all RCU tests are run from check_rcu() iirc.  This did yield results of
> > failures that had to be addressed so I'm somewhat confident that it's
> > actually working.
> 
> OK, I guess I can feel relieved that I can still read code.  ;-)

Oh, and I should hasten to add that for a data structure fully protected
by a reader-writer lock, sequential tests can be reasonably effective.
At least assuming readers really truly only read...

							Thanx, Paul

> > >From your wording I'm gathering I need to increase this by a lot more
> > test cases?
> 
> I would feel better with the addition of something that looked more
> like a stress test.  For but one example, is there some combination
> of several successive update operations that can mess up slow readers
> (that is, readers that are interrupted or preempted, and thus have
> multiple updates happen while they are traversing the tree)?  If so,
> the current tests will not find it.
> 
> 							Thanx, Paul