by eivind and des. Add entities for them. While I'm there, add a
task for expanding the profiling tool to include sx locks, since we'll
want to be able to measure that sort of lock contention also.
for pushing down Giant on malloc()/free(). The first of these has been
completed by Jeff Roberson as part of the recent UMA commit, and the
second is a work-in-progress by Jeff (he has a remaining Witness warning
to clear up before it's done).
enable/disable state. Note that it's on-going, and so far I've seen
commits from at least {benno, dfr, imp, jhb}. If you did some of this
e-mail me and I'll add you. Someone let me know when it's done.
Jason Evan's public_html directory.
- Link to archived email messages from docs.freebsd.org, rather than
non existant text files in the local directory.
- Correct link to Chuck Patterson's slides, which reside in ~jasone,
not the local directory.
- Break out lockmgr exclusive and sx/mutex tasks from one another, and
leave the original (completed) movement of mutex pool initialization
task as it's own thing.
- Create the task for moving to purely exclusive locks in VM rather than
lockmgr shared locks. This task will involve implementation, then testing
to see if it actually hurts. If this is possible, it will greatly
simplify the transition to new locking primitives. Assign this to
green since he's expressed willingness to work on it.
- Create the task for moving from lockmgr to either mutexes or exclusive
sxlocks for VM. At that point, it should be possible to start pushing
Giant down into VM somewhere, subject to lack of locking for a few
primitives that will still require it, and for VFS/pmap interactions.
system with a simple exclusive locking scheme, avoiding livelock and
deadlock scenarios using the new locking primitives, per Matt Dillon's
description on freebsd-current.
Obtained from: 200203180048.g2I0mOc40231@apollo.backplane.com
- Alfred has pushed down Giant for a number of fd-related operations,
including read/write/pread/pwrite, +other consumers into the per-subsystem
fileop code. Record this as done.
- Add a task to push down Giant for the remaining such calls, including
readv/writev which currently still require Giant for memory management
in handling struct iovec arrays. Record this as un-owned.
structures behind a 'sellock' to prevent lock order reversals relating
the processes in the select() code. Update the task entry to move it
to the Done section as of today.
- VOP_GETATTR() change to shared locks + namei() updates to support this
- General VFS assertion review and corrections
Move the first to the WIP section, since Jeff Roberson just committed
supporting infrastructure for this in the form of namei's LOCKSHARED.
Leave the second in the New section.
work pushes the selinfo structure under a seperate lock and allows
select-related behavior to be pushed out from under Giant. Patches
were recently posted to freebsd-smp, so make it a WIP.
Add an entity for Chad since he didn't have one already.
which is currently not protected yet used outside of Giant due to
the struct filedesc pushdown. While a sub-set of the overall proc locking
task, this appears to be seperable, and in progress, so break it out
into its own task with responsible of 'tanimura'. Currently, there
can be panics under high load with a corrupted p_fd as a result of this
lack of locking.
Bugs reported by: fenner
count cleanup, and then mark as done since phk just committed the
expected changes. There might be more outstanding issues with this,
but the known ones are now covered.
these entities may be used by other documents. Also, prepend "a." to
the developer entities, to clearly define the namespace used for this
purpose (as done in doc/).
are many native ABI calls with Giant still being set in syscalls.master.
Maxime Henrion is preparing patches that address this, and remove the
M* stuff in syscalls.master, so stick in his name as a co-conspirator.
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.
