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>