From owner-freebsd-net@FreeBSD.ORG Thu Aug 29 16:02:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E36A8E26; Thu, 29 Aug 2013 16:02:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1B0E23FE; Thu, 29 Aug 2013 16:02:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7183BB924; Thu, 29 Aug 2013 12:02:19 -0400 (EDT) From: John Baldwin To: Scott Long Subject: Re: [rfc] migrate lagg to an rmlock Date: Thu, 29 Aug 2013 12:01:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308291042.13282.jhb@freebsd.org> <41614148-3900-4FE0-88AC-40F10DAE2030@yahoo.com> In-Reply-To: <41614148-3900-4FE0-88AC-40F10DAE2030@yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291201.04131.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 12:02:19 -0400 (EDT) Cc: FreeBSD Net , Adrian Chadd , freebsd-current@freebsd.org, Robert Watson , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:02:21 -0000 On Thursday, August 29, 2013 11:37:08 am Scott Long wrote: > > On Aug 29, 2013, at 7:42 AM, John Baldwin 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