Date: Mon, 19 Nov 2001 08:51:01 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@wemm.org>, freebsd-arch@FreeBSD.ORG Subject: Re: Need review - patch for socket locking and ref counting Message-ID: <XFMail.011119085101.jhb@FreeBSD.org> In-Reply-To: <200111171830.fAHIUBu80966@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-Nov-01 Matthew Dillon wrote: >:> 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. I think it's less of a mess than you might think it is. mtx_pool_find(&sx_lock_pool, sx) is obviously more correct than mtx_pool_find(&foobar_lock_pool, sx). I don't think we need 100 pools. >:> 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. Then that makes them unusable for any leaf locks. Different locks have different needs. >: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, They were specifically requested and I don't want to shoot the XFS effort in the head. I agree that they are of limited usefulness, however. >: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. If you could fix the locking for VM maps then to not require upgrade/downgrade, that would be greatly appreciated. :) Note that devfs also uses upgrade/downgrade atm as well via lockmgr locks that will become sx locks. -- 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.011119085101.jhb>