Warner indicated at the developer summit that he'd be willing to give it
a shot, assign ownership to him for the time being. While I'm at it,
add an entity for Warner.
- Proc locking for debugging interfaces and procfs
- Proc locking for monitoring sysctls, such as those used by 'ps'
Since jhb has patches that cover this, I'll assign them to him for now.
Hopefully they're on the commit fast path, and we can remove these
RSN. I'm attempting to remove the 'proc locking' task item, since it's
sufficiently broad as to not be very instructive for those reading the
task list.
(1) Add the p_ucred -> td_ucred task explicitly, rather than relying on
the larger "proc locking" task. Assign to John since he just committed
a bunch, and I don't know if he's done (it looks like he is, so should
close this task).
(2) Add an item for the suser and p_can*() API switches to use thread
instead of process pointers. Since John has patches, and has indicated
an impending commit, assign ownership to him.
(3) arr has indicated he's taking a stab at adding locking to the kernel
linker and module structures. Go ahead and assign ownership to him.
(1) Note that Alfred has completed "simple" locking for pipes: this
includes small reads and writes that don't trigger VM optimizations,
and the SIGIO, fsetown(), and related inter-process evil for pipes.
Another item off the check-list for 5.0-RELEASE.
(2) Create two new tasks: sigio/setfown/... components of pipes. Mark
this as WIP, and assign to Alfred. Create a VM optimizations pipe
task without an owner: we'll probably get this for free as part
of fine-grained VM locking when that happens.
Note that the remaining ABIs have not yet had Giant pushed down, including
those I could find in a quick scan of the tree:
Linux i386 \
Linux AXP / Some of these may be overlapped
SVR4 i386
OSF/1 AXP
IBCS i386
without an owner. To measure the effectiveness of our locking strategy,
optimality of mutex pools, etc, we'll need a tool that tells us what
locks are the "hottest", as well as other useful statistics such as
average latency to wait on a lock, perhaps throughput on the lock, etc.
This task will require some relatively in-depth analysis of what we need
to know, not just hacking, but should prove interesting and highly
valuable.
Add an additional entry indicating that the locking of jail occurred
about this time last year. jhb had to redo things a bit for the
proc locking work, but I figured I might as well add it anyway.
mentioned in the list because details aren't, but this is complicated
by the presence of VM magic in the pipe implementation. However, VM
isn't involved in small pipe operations, and small pipe operations are
critical to the performance of large build operations involving make.
It looks like pushing small pipe operations out from under giant would
have a large impact on build performance, making this an appealing
target as file_ops becomes safe.
This still needs a lot of work, but at least now it doesn't claim that
we're just in the planning phase. Also, combine Jason's first-person
account of his time at Sun into the 'Port History' section. Add a
'Latest News' section to contain the newest milestones.
