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