Date: Sat, 17 Nov 2001 02:23:56 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-arch@FreeBSD.ORG, Peter Wemm <peter@wemm.org> Subject: Re: Need review - patch for socket locking and ref counting Message-ID: <XFMail.011117022356.jhb@FreeBSD.org> In-Reply-To: <200111170300.fAH30dv75857@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-Nov-01 Matthew Dillon wrote: > I've thought about it a bit and I've come to the conclusion that > we should *not* have multiple mutex pools. > > The single pool we have works wonderfully for interlock operations. > For example, the interlocks used inside the sxlock structure and code, > and inside the lockmgr structure and code (the lockmgr previously used > its own hacked up pool for its interlock). The pool effectively cuts > the size and overhead of higher level structures - such as sxlocks - down > considerably. They've added 4 new lock order reversals to my boot messages. For that we need a pool of mutexes with MTX_NOWITNESS. However, MTX_NOWITNESS is not appropriate for locks outside of sx and lockmgr backing locks. > But our ability to use pools for higher level constructs, like the > sxlocks > themselves, is severely limited. My attempts so far have only resulted > in more obfuscated code. ??? If you want a sx lock pool, it would be just as simple as the mtx pool you have now, just s/mtx/sx/, and thus sx_pool_slock, etc. Not that complicated. Not sure it is all that useful either though. > 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. > 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. > 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 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. -- John Baldwin <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011117022356.jhb>