PERFORCE change 96007 for review
jb at what-creek.com
Mon Apr 24 22:04:07 UTC 2006
On Mon, Apr 24, 2006 at 05:48:58PM -0400, John Baldwin wrote:
> 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.
What I would like to do is have DTrace call a kern_linker
function specifying a callback function that the linker
would call for each module. The function needs to pass back
an opaque argument, plus a pointer to the linker file structure.
DTrace wants the module info not to change while it looks at
the contents of the linker file structure. DTrace doesn't
need to know how the modules are listed or locked, but it
definitely needs to be able to allocate memory with wait
while it is looking at the module data.
> 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.
I agree, but the structure of Sun's code does all it's allocations
except the buffers with VM_SLEEP. It's a major rewrite of their
code to fall back gracefully if memory isn't available.
More information about the p4-projects