Date: Fri, 16 Nov 2001 19:00:39 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Peter Wemm <peter@wemm.org>, freebsd-arch@FreeBSD.ORG Subject: Re: Need review - patch for socket locking and ref counting Message-ID: <200111170300.fAH30dv75857@apollo.backplane.com> References: <XFMail.011115124557.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<dillon@backplane.com>
: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 <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?200111170300.fAH30dv75857>