Date: Thu, 29 Aug 2013 10:42:13 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: FreeBSD Net <freebsd-net@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, Robert Watson <rwatson@freebsd.org>, "Alexander V. Chernikov" <melifaro@ipfw.ru> Subject: Re: [rfc] migrate lagg to an rmlock Message-ID: <201308291042.13282.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1308241511400.92711@fledge.watson.org> References: <CAJ-Vmo=VKVDEmmPrTbob6Ft%2B7FWypodNoL36Og=7p_CXBSfktg@mail.gmail.com> <5218AA36.1080807@ipfw.ru> <alpine.BSF.2.00.1308241511400.92711@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308291042.13282.jhb>