From owner-freebsd-arch Fri Nov 16 19: 0:43 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 9E05F37B419; Fri, 16 Nov 2001 19:00:40 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fAH30dv75857; Fri, 16 Nov 2001 19:00:39 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Nov 2001 19:00:39 -0800 (PST) From: Matthew Dillon Message-Id: <200111170300.fAH30dv75857@apollo.backplane.com> To: John Baldwin Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG 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'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. 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. 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. 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. 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. -Matt Matthew Dillon :On 15-Nov-01 Peter Wemm wrote: :> Matthew Dillon wrote: :> :>> +static __inline :>> +struct mtx * :>> +_mtx_pool1_find(void *ptr) :>> +{ :>> + return(&mtx_pool_ary[(((int)ptr ^ ((int)ptr >> 6)) & MTX_POOL_XMASK) | :>> 0 :> ]); :>> +} :> :> At the very least, this is not going to compile very well on 64 bit machines. :> You cannot cast a pointer to an int. At needs to be uintptr_t at minimum. : :I would also prefer a generic mechanism for multiple pools with a struct :mtx_pool containing a count, index for alloc, and pointer to the array of :locks and pass it as the first arg to mtx_pool_foo(). This would also entail a :mtx_pool_init(struct mtx_pool *mp, int size); and a :mtx_pool_destroy(struct mtx_pool *mp); This is much cleaner and extensible :than hardcoding 4 pools of equal size. : :-- : :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