PERFORCE change 96007 for review

[John Baldwin]

On Monday 24 April 2006 17:31, John Birrell wrote:
> 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.

Typically one does:

	for (i = 0; i <= mp_maxid; i++) {
		if (CPU_ABSENT(i))
			continue;
		...
	}

 
> 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?

1) I've already completely redone all of the locking in the
kernel linker to use a big sx lock around the whole kernel
linker.  I have to tidy up some issues with ndis still.

2) Tell me what dtrace is trying to do and let's see if we
can provide an API hook in the kernel linker for it instead
of having DTrace grovel around in the linker's internals.
Then DTrace doesn't need to be aware of any locking for the
kernel linker.

3) Generally speaking it is better (if possible) to preallocate
resources before acquiring a lock so that you don't hold the
lock as long.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org