On Thursday, August 29, 2013 11:37:08 am Scott Long wrote: > > On Aug 29, 2013, at 7:42 AM, John Baldwin <j...@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 Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
