From owner-freebsd-arch Sat Nov 17 10:30:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D27D637B417; Sat, 17 Nov 2001 10:30:12 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fAHIUBu80966; Sat, 17 Nov 2001 10:30:11 -0800 (PST) (envelope-from dillon) Date: Sat, 17 Nov 2001 10:30:11 -0800 (PST) From: Matthew Dillon Message-Id: <200111171830.fAHIUBu80966@apollo.backplane.com> To: John Baldwin Cc: freebsd-arch@FreeBSD.ORG, Peter Wemm Subject: Re: Need review - patch for socket locking and ref counting References: 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 :> 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. : :> 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. Again. Difficulty is not the problem here. Confusion and Mess are the problems. It is not necessarily a good idea to take every locking API we have and give each one dozens of features and capabilities that go mostly unused. :> For similar reasons I believe we should also simplify the APIs to :> other low level constructs. I would like to simplify the SX lock :> API (get rid of sx_tryupgrade() and sx_downgrade()), and I would :> like to see a more simplified structure if possible in order to :> make SX locks more useful as embedded entities in higher level system :> structures such as TCP sockets or PCBs. : :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, :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. -Matt Matthew Dillon :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