On Mon, May 17, 2021 at 04:30:53PM +0000, Liam Howlett wrote: > * Paul E. McKenney <paulmck@xxxxxxxxxx> [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
