#
ed6a7c42 |
| 11-Nov-2006 |
Kip Macy <kmacy@FreeBSD.org> |
tinderbox fix
|
#
cf2c39e7 |
| 11-Nov-2006 |
Kip Macy <kmacy@FreeBSD.org> |
remove lingering call to rd(tick)
|
#
83b72e3e |
| 11-Nov-2006 |
Kip Macy <kmacy@FreeBSD.org> |
missed nits replacing mutex with lock
|
#
7c0435b9 |
| 11-Nov-2006 |
Kip Macy <kmacy@FreeBSD.org> |
MUTEX_PROFILING has been generalized to LOCK_PROFILING. We now profile wait (time waited to acquire) and hold times for *all* kernel locks. If the architecture has a system synchronized TSC, the prof
MUTEX_PROFILING has been generalized to LOCK_PROFILING. We now profile wait (time waited to acquire) and hold times for *all* kernel locks. If the architecture has a system synchronized TSC, the profiling code will use that - thereby minimizing profiling overhead. Large chunks of profiling code have been moved out of line, the overhead measured on the T1 for when it is compiled in but not enabled is < 1%.
Approved by: scottl (standing in for mentor rwatson) Reviewed by: des and jhb
show more ...
|
Revision tags: release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0 |
|
#
3f08bd8b |
| 28-Jan-2006 |
John Baldwin <jhb@FreeBSD.org> |
Add a basic reader/writer lock implementation to the kernel. This implementation is by no means perfect as far as some of the algorithms that it uses and the fact that it is missing some functionali
Add a basic reader/writer lock implementation to the kernel. This implementation is by no means perfect as far as some of the algorithms that it uses and the fact that it is missing some functionality (try locks and upgrades/downgrades are not there yet), however it does seem to work in my local testing. There is more detail in the comments in the code, but the short version follows.
A reader/writer lock is very much like a regular mutex: it cannot be held across a voluntary sleep; it can be acquired in an interrupt thread; if the lock is held by a writer then the priority of any threads that block on the lock will be lent to the owner; the simple case lock operations all are done in a single atomic op. It also shares some similiarities with sx locks: it supports reader/writer semantics (multiple readers, but single writers); readers are allowed to recurse, but writers are not.
We can extend this implementation further by either improving algorithms or adding new functionality, but this should at least give us a base to work with now.
Reviewed by: arch (in theory) Tested on: i386 (4 cpu box with a kernel module that used 4 threads that randomly chose between read locks and write locks that ran w/o panicing for over a day solid. It usually panic'd within a few seconds when there were bugs during testing. :) The kernel module source is available on request.)
show more ...
|
#
25e498b4 |
| 18-Jan-2006 |
John Baldwin <jhb@FreeBSD.org> |
Always include the lock_classes[] array in the kernel. The "is it a spinlock" test in mtx_destroy() needs it even in non-debug kernels.
Reported by: danfe
|
#
6ef970a9 |
| 17-Jan-2006 |
John Baldwin <jhb@FreeBSD.org> |
Bah. Fix 'show lock' to actually be compiled in. I had just fixed this in p4 but had an older subr_lock.c on the machine I committed to CVS from.
|
#
83a81bcb |
| 17-Jan-2006 |
John Baldwin <jhb@FreeBSD.org> |
Add a new file (kern/subr_lock.c) for holding code related to struct lock_obj objects: - Add new lock_init() and lock_destroy() functions to setup and teardown lock_object objects including KTR log
Add a new file (kern/subr_lock.c) for holding code related to struct lock_obj objects: - Add new lock_init() and lock_destroy() functions to setup and teardown lock_object objects including KTR logging and registering with WITNESS. - Move all the handling of LO_INITIALIZED out of witness and the various lock init functions into lock_init() and lock_destroy(). - Remove the constants for static indices into the lock_classes[] array and change the code outside of subr_lock.c to use LOCK_CLASS to compare against a known lock class. - Move the 'show lock' ddb function and lock_classes[] array out of kern_mutex.c over to subr_lock.c.
show more ...
|