Date: Mon, 24 Apr 2006 21:31:35 +0000 From: John Birrell <jb@what-creek.com> To: John Baldwin <jhb@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 96007 for review Message-ID: <20060424213134.GA62456@what-creek.com> In-Reply-To: <200604241637.08322.jhb@freebsd.org> References: <200604241913.k3OJDEAq055317@repoman.freebsd.org> <200604241637.08322.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 24, 2006 at 04:37:07PM -0400, John Baldwin wrote:
> On Monday 24 April 2006 15:13, John Birrell wrote:
> > ASSERT(MUTEX_HELD(&dtrace_lock));
> > - for (i = 0; i < mp_ncpus; i++) {
> > + for (i = 0; i < mp_maxid; i++) {
>
> Use <= with mp_maxid. The range is 0 .. mp_maxid (inclusive).
>
Yeah I see that now, thanks. I've weeded out mp_ncpus.
What I really need to do is to use the cpu list and only allocate
buffers for the cpus that exist. That's what Solaris does. I'm
not sure what the locking issues are with doing that.
DTrace also needs to go through the module list and it wants
to hold a lock on that, but also allocate memory with wait.
So what I really need is a version of the sx lock which is
recursive for exclusive locks.
Then I need to change the kern/kern_linker.c code to use that
sort of lock, not just a mutex.
Any thoughts on that?
--
John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060424213134.GA62456>