From owner-freebsd-arch Mon Nov 19 8:51:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id CEB0437B419 for ; Mon, 19 Nov 2001 08:51:11 -0800 (PST) Received: (qmail 10365 invoked from network); 19 Nov 2001 16:51:21 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Nov 2001 16:51:21 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200111171830.fAHIUBu80966@apollo.backplane.com> Date: Mon, 19 Nov 2001 08:51:01 -0800 (PST) From: John Baldwin To: Matthew Dillon Subject: Re: Need review - patch for socket locking and ref counting Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 17-Nov-01 Matthew Dillon wrote: >:> I think the pool implementation should be left as it is and used ONLY >:> for interlocks and 'leaf' locks, as I originally designed it. Adding >:> multiple-pools (and the allocation / freeing / management headaches >:> that go along with that) will only create a mess. I don't think it's >:> even possible to use a pool of sx locks safely, for example, even with >:> the multiple pool concept. >: >:Errr, it's all of two extra functions and one extra parameter to the others. >:This should not be difficult. > > Difficulty isn't the problem. Confusion and Mess are the problems. I think it's less of a mess than you might think it is. mtx_pool_find(&sx_lock_pool, sx) is obviously more correct than mtx_pool_find(&foobar_lock_pool, sx). I don't think we need 100 pools. >:> The current pool code is nice because it simplifies our code base >:> somewhat rather then make it more complex. I see absolutely no need >:> for a multiple-pool mechanism at this time. >: >:Are you planning to turn on MTX_NOWITNESS then and then be forced not to use >:pool locks for anything besides sx and lockmgr backing locks since they won't >:have WITNESS checks performed for them? Different types of locks have >:different types of requirements. > > I'll turn on MTX_NOWITNESS. Then that makes them unusable for any leaf locks. Different locks have different needs. >:Err, the try_upgrade and downgrade are trivial and add nothing to the sx lock >:structure itself. They were also specifically requested for use in porting >:XFS >:to FreeBSD and are useful in other areas such as Brian's changes to make > > I don't think it's worth it just for XFS, They were specifically requested and I don't want to shoot the XFS effort in the head. I agree that they are of limited usefulness, however. >:vm_map's use sx locks instead of lockmgr locks. We can always optimize the >:locks later, it is more important right now to actually put locks in places >:so >:that actual multithreading can occur. > > I don't see it as being necessary for VM maps. Since interrupts are in > their own threads VM maps can probaly do away with much of the junk they > needed for -stable. If you could fix the locking for VM maps then to not require upgrade/downgrade, that would be greatly appreciated. :) Note that devfs also uses upgrade/downgrade atm as well via lockmgr locks that will become sx locks. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message