On Thursday, August 29, 2013 11:37:08 am Scott Long wrote: > > On Aug 29, 2013, at 7:42 AM, John Baldwin <jhb_at_freebsd.org> wrote: > > > On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote: > >> There are a number of other places in the kernel where migration to an rmlock > >> makes sense -- however, some care must be taken for four reasons: (1) while > >> read locks don't experience line contention, write locking becomes observably > >> e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike rwlocks, > >> more expensive so is not suitable for all rwlock line contention spots -- > >> implement reader priority propagation, so you must reason about; and (3) > >> historically, rmlocks have not fully implemented WITNESS so you may get less > >> good debugging output. if_lagg is a nice place to use rmlocks, as > >> reconfigurations are very rare, and it's really all about long-term data > >> stability. > > > > 3) should no longer be an issue. rmlocks now have full WITNESS and assertion > > support (including an rm_assert). > > > > However, one thing to consider is that rmlocks pin readers to CPUs while the > > read lock is held (which rwlocks do not do). > > And this is not a problem for the application that we're giving it in the > lagg driver. That is likely true. I was merely tweaking Robert's general guidelines re: rmlock. -- John BaldwinReceived on Thu Aug 29 2013 - 14:02:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC