but undefined: the de facto definition that appears to be in use, and
that I'm assuming still applies, is the following:
The "Responsible" field identifies a developer who has expressed
willingness to be responsible for completing the identified task;
this doesn't preclude others working on it, but suggests that
coordination with the responsible party might be appropriate so as
to avoid unnecessary duplication of work, and to maximize forward
progress.
Requested by: "Michael G. Petry" <petry@NetMasters.Com>
- Claim TrustedBSD locking. This isn't in the tree yet, but will begin
to migrate in in a month or so, and I am asserting to myself that it
will be locked when it arrives :-).
- Assign a variety of VFS locking-related tasks to Jeff Roberson. He
volunteered to work on these at BSDCon, so as a personal favor to him,
I'm making sure he can't forget. While I'm at it, add an entity for
him. The tasks he described include:
- Cleaning up locking within the vnode, including documenting
the various implicit and explicit locks there.
- Moving to explicit counting of soft references.
- Move towards using sx locks instead of lockmgr once this cleanup
is done.
- Moving towards being able to perform VOP_GETATTR() shared,
to reduce lock contention.
- Generally review vnode and VFS locking for SMP-safety.
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.
