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@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. ;-) 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
