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