On Sat, Jan 18, 2020 at 03:19:37PM -0500, Joel Fernandes wrote: > On Fri, Jan 17, 2020 at 08:34:58PM -0800, Paul E. McKenney wrote: > > On Fri, Jan 17, 2020 at 09:34:34PM -0500, Joel Fernandes wrote: > > > On Fri, Jan 17, 2020 at 03:17:56PM -0800, Paul E. McKenney wrote: > > > [...] > > > > But rcutorture already has tests for RCU priority boosting. Or are those > > > > failing in some way? > > > > > > Yes there are tests, but I thought of just a simple experiment to study this. > > > Purely since it is existing RCU kernel code that I'd like to understand. And > > > me/Daniel are also looking into possibly using run-time / trace-based > > > verification some of these behaviors. > > > > The functionality of rcu_state.cbovld should make that more entertaining. > > > > But I would guess that the initial model would ignore memory footprint > > and just model RCU priority boosting as kicking in a fixed time after > > the beginning of the grace period. > > > > Or do you guys have something else in mind? > > Yes, that is the idea. And then turn the model into a unit test (for the > measurement). Though I am also personally trying to convince myself that a > unit test based on a model is better than the test in the kernel module I > just posted. We're just looking at applying Daniel's modeling work to > verification of behaviors like these. > > A poor-man's alternative of a model-based test is just making sure that > synchronize_rcu() finishes in a bounded period of time (basically test by > observation than test by model) similar to what my kernel module did. But I > guess a model based test would be more accurate and more strict about what is > considered a pass vs fail. In one sense, fair enough. But in a more practical sense, why would anyone put synchronize_rcu() anywhere near their real-time fastpaths? Even synchronize_rcu_expedited() would be a rather brave choice for such a fastpath. > I was also studying SRCU and could not find tracepoints so I am thinking of > adding some to aid the study. I know for Tree-SRCU you are using timers and > workqueues but the concept hasn't largely changed since [1] was written > right? At one point I had tracepoints for SRCU on my list, but the discussions of tracepoints possibly being user API scared me off. > [1] https://lwn.net/Articles/202847/ SRCU has been rewritten from scratch something like three times since that article was published. The current version is only a few years old. And there is some motivation for more modifications due to the size of the srcu_struct structure. (Maybe dynamically allocating the srcu_node array or some such, though this is not free of hazard and hassle, either.) Thus far, all complaints about the large size have been handled by other means, but there have been several such complaints. In addition, the use of workqueues is still a bit on the experimental side. Looking good thus far, but the code is yet young. But yes, had the code remained unchanged for 14 years, there wouldn't be much downside to adding tracepoints. But the code is less than three years old. Thanx, Paul > thanks! > > - Joel > > > Thanx, Paul > > > > PS. Steve, yes, I do well remember our earlier discussions about readers > > inheriting priority from the highest-priority synchronize_rcu(). ;-)
