Date: Sat, 19 Jan 2002 12:08:22 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org> Cc: smp@FreeBSD.ORG Subject: Re: help with mutex_pool please? Message-ID: <200201192008.g0JK8MD51338@apollo.backplane.com> References: <20020119080125.X13686@elvis.mu.org> <200201191942.g0JJgLK50974@apollo.backplane.com> <20020119114848.A13686@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:No, it locks hard. What I can do is see if it's either uidinfo or
:file locking that's causing it (or both) and get back to you. That
:is unless you want to take a shot at it.
:
:Perhaps you can suggest some debugging KTR/printfs to be added to the
:subsystem?
:
:Btw, mtx_pool_lock is sort of misleading, I thought it meant "lock
:a pool mutex", but it really means lock the pool containing the
:mutex. Maybe mtx_pool_lock/unlock shouldn't take void *, they
:should take a "struct mutex_pool *" or something and make the caller
:explicitly do the mutex_pool_find?
:
:--
:-Alfred Perlstein [alfred@freebsd.org]
Make sure you recompile the entire kernel and all its modules
from scratch as well.
I don't understand re: mtx_pool_lock(). It locks a pool
mutex which it calculates based on a void * ptr. It's meant
to short-cut very simple leaf level mutexes for structures
in which you might not otherwise want to embed a mutex pointer.
My intention was to eventually use it for really small
structures like vm_page's and pmap entries where you can't
afford to bloat the structure.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201192008.g0JK8MD51338>