On 24 Aug 2013, at 17:36, Alfred Perlstein wrote: >> We should distinguish "lock contention" from "line contention". When >> acquiring a rwlock on multiple CPUs concurrently, the cache lines used to >> implement the lock are contended, as they must bounce between caches via the >> cache coherence protocol, also referred to as "contention". In the if_lagg >> code, I assume that the read-only acquire of the rwlock (and perhaps now >> rmlock) is for data stability rather than mutual exclusion -- e.g., to allow >> processing to completion against a stable version of the lagg configuration. >> As such, indeed, there should be no lock contention unless a configuration >> update takes place, and any line contention is a property of the locking >> primitive rather than data model. >> >> 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. > > Robert, what do you think about a quick swap of the ifnet structures to > counter before 10.x?
Could you be more specific about the proposal you're making? Robert _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
