#
2287aa04 |
| 27-Mar-2010 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
MFC r205626:
Print the pointer to the lock with the panic message. The previous panic: rw lock not unlocked was not really helpful for debugging. Now one can at least call show l
MFC r205626:
Print the pointer to the lock with the panic message. The previous panic: rw lock not unlocked was not really helpful for debugging. Now one can at least call show lock <ptr> form ddb to learn more about the lock.
show more ...
|
#
2430ab46 |
| 24-Mar-2010 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Print the pointer to the lock with the panic message. The previous panic: rw lock not unlocked was not really helpful for debugging. Now one can at least call show lock <ptr> form ddb to learn more
Print the pointer to the lock with the panic message. The previous panic: rw lock not unlocked was not really helpful for debugging. Now one can at least call show lock <ptr> form ddb to learn more about the lock.
MFC after: 3 days
show more ...
|
Revision tags: release/7.3.0_cvs, release/7.3.0 |
|
#
1a0fda2b |
| 04-Mar-2010 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
IFH@204581
|
Revision tags: release/8.0.0_cvs, release/8.0.0 |
|
#
3f4609ac |
| 12-Oct-2009 |
Attilio Rao <attilio@FreeBSD.org> |
MFC r197643, r197735: When releasing a read/shared lock we need to use a write memory barrier in order to avoid, on architectures which doesn't have strong ordered writes, CPU instructions reordering
MFC r197643, r197735: When releasing a read/shared lock we need to use a write memory barrier in order to avoid, on architectures which doesn't have strong ordered writes, CPU instructions reordering.
Approved by: re (kib)
show more ...
|
#
1ee774f6 |
| 02-Oct-2009 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
- MFC
|
#
ddce63ca |
| 30-Sep-2009 |
Attilio Rao <attilio@FreeBSD.org> |
When releasing a read/shared lock we need to use a write memory barrier in order to avoid, on architectures which doesn't have strong ordered writes, CPU instructions reordering.
Diagnosed by: fabio
When releasing a read/shared lock we need to use a write memory barrier in order to avoid, on architectures which doesn't have strong ordered writes, CPU instructions reordering.
Diagnosed by: fabio Reviewed by: jhb Tested by: Giovanni Trematerra <giovanni dot trematerra at gmail dot com>
show more ...
|
#
10b3b545 |
| 17-Sep-2009 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Merge from head
|
#
7d4b968b |
| 17-Sep-2009 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Merge from head up to r188941 (last revision before the USB stack switch)
|
#
c90c9ddd |
| 09-Sep-2009 |
Attilio Rao <attilio@FreeBSD.org> |
Adaptive spinning for locking primitives, in read-mode, have some tuning SYSCTLs which are inappropriate for a daily use of the machine (mostly useful only by a developer which wants to run benchmark
Adaptive spinning for locking primitives, in read-mode, have some tuning SYSCTLs which are inappropriate for a daily use of the machine (mostly useful only by a developer which wants to run benchmarks on it). Remove them before the release as long as we do not want to ship with them in.
Now that the SYSCTLs are gone, instead than use static storage for some constants, use real numeric constants in order to avoid eventual compiler dumbiness and the risk to share a storage (and then a cache-line) among CPUs when doing adaptive spinning together.
Pleasse note that the sys/linker_set.h inclusion in lockmgr and sx lock support could have been gone, but re@ preferred them to be in order to minimize the risk of problems on future merging.
Please note that this patch is not a MFC, but an 'edge case' as commit directly to stable/8, which creates a diverging from HEAD.
Tested by: Giovanni Trematerra <giovanni dot trematerra at gmail dot com> Approved by: re (kib)
show more ...
|
#
cbd59a4f |
| 08-Sep-2009 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
- MFC from head@196987
|
#
7e2d0af9 |
| 17-Aug-2009 |
Attilio Rao <attilio@FreeBSD.org> |
MFC r196334:
* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to a pointer-fetching specific operation check. Consequently, rename the operation ASSERT_ATOMIC_LOAD_PTR(). * Fi
MFC r196334:
* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to a pointer-fetching specific operation check. Consequently, rename the operation ASSERT_ATOMIC_LOAD_PTR(). * Fix the implementation of ASSERT_ATOMIC_LOAD_PTR() by checking directly alignment on the word boundry, for all the given specific architectures. That's a bit too strict for some common case, but it assures safety. * Add a comment explaining the scope of the macro * Add a new stub in the lockmgr specific implementation
Tested by: marcel (initial version), marius Reviewed by: rwatson, jhb (comment specific review) Approved by: re (kib)
show more ...
|
#
353998ac |
| 17-Aug-2009 |
Attilio Rao <attilio@FreeBSD.org> |
* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to a pointer-fetching specific operation check. Consequently, rename the operation ASSERT_ATOMIC_LOAD_PTR(). * Fix the implemen
* Change the scope of the ASSERT_ATOMIC_LOAD() from a generic check to a pointer-fetching specific operation check. Consequently, rename the operation ASSERT_ATOMIC_LOAD_PTR(). * Fix the implementation of ASSERT_ATOMIC_LOAD_PTR() by checking directly alignment on the word boundry, for all the given specific architectures. That's a bit too strict for some common case, but it assures safety. * Add a comment explaining the scope of the macro * Add a new stub in the lockmgr specific implementation
Tested by: marcel (initial version), marius Reviewed by: rwatson, jhb (comment specific review) Approved by: re (kib)
show more ...
|
#
21845eba |
| 14-Aug-2009 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
MFC r196226:
Add a new macro to test that a variable could be loaded atomically. Check that the given variable is at most uintptr_t in size and that it is aligned.
Note: ASSERT_ATOMIC_LOAD(
MFC r196226:
Add a new macro to test that a variable could be loaded atomically. Check that the given variable is at most uintptr_t in size and that it is aligned.
Note: ASSERT_ATOMIC_LOAD() uses ALIGN() to check for adequate alignment -- however, the function of ALIGN() is to guarantee alignment, and therefore may lead to stronger alignment enforcement than necessary for types that are smaller than sizeof(uintptr_t).
Add checks to mtx, rw and sx locks init functions to detect possible breakage. This was used during debugging of the problem fixed with r196118 where a pointer was on an un-aligned address in the dpcpu area.
In collaboration with: rwatson Reviewed by: rwatson
Approved by: re (kib)
show more ...
|
#
8d518523 |
| 14-Aug-2009 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Add a new macro to test that a variable could be loaded atomically. Check that the given variable is at most uintptr_t in size and that it is aligned.
Note: ASSERT_ATOMIC_LOAD() uses ALIGN() to chec
Add a new macro to test that a variable could be loaded atomically. Check that the given variable is at most uintptr_t in size and that it is aligned.
Note: ASSERT_ATOMIC_LOAD() uses ALIGN() to check for adequate alignment -- however, the function of ALIGN() is to guarantee alignment, and therefore may lead to stronger alignment enforcement than necessary for types that are smaller than sizeof(uintptr_t).
Add checks to mtx, rw and sx locks init functions to detect possible breakage. This was used during debugging of the problem fixed with r196118 where a pointer was on an un-aligned address in the dpcpu area.
In collaboration with: rwatson Reviewed by: rwatson Approved by: re (kib)
show more ...
|
#
7e857dd1 |
| 12-Jun-2009 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
- Merge from HEAD
|
#
2e03f452 |
| 04-Jun-2009 |
Jung-uk Kim <jkim@FreeBSD.org> |
Resync with head.
|
#
f0830182 |
| 02-Jun-2009 |
Attilio Rao <attilio@FreeBSD.org> |
Handle lock recursion differenty by always checking against LO_RECURSABLE instead the lock own flag itself.
Tested by: pho
|
#
a571ad41 |
| 29-May-2009 |
John Baldwin <jhb@FreeBSD.org> |
Remove extra cpu_spinwait() invocations. This should really only be used in tight spin loops, not in these edge cases where we restart a much larger loop only a few times.
Reviewed by: attilio
|
#
fa29f023 |
| 29-May-2009 |
John Baldwin <jhb@FreeBSD.org> |
Tweak a few comments on adaptive spinning.
|
#
a5aedd68 |
| 26-May-2009 |
Stacey Son <sson@FreeBSD.org> |
Add the OpenSolaris dtrace lockstat provider. The lockstat provider adds probes for mutexes, reader/writer and shared/exclusive locks to gather contention statistics and other locking information fo
Add the OpenSolaris dtrace lockstat provider. The lockstat provider adds probes for mutexes, reader/writer and shared/exclusive locks to gather contention statistics and other locking information for dtrace scripts, the lockstat(1M) command and other potential consumers.
Reviewed by: attilio jhb jb Approved by: gnn (mentor)
show more ...
|
Revision tags: release/7.2.0_cvs, release/7.2.0 |
|
#
9c797940 |
| 13-Apr-2009 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
- Merge from HEAD
|
#
1723a064 |
| 15-Mar-2009 |
Jeff Roberson <jeff@FreeBSD.org> |
- Wrap lock profiling state variables in #ifdef LOCK_PROFILING blocks.
|
#
1829d5da |
| 12-Mar-2009 |
Warner Losh <imp@FreeBSD.org> |
Update the projects tree to a newer FreeBSD current.
|
#
c90c9021 |
| 26-Feb-2009 |
Ed Schouten <ed@FreeBSD.org> |
Remove even more unneeded variable assignments.
kern_time.c: - Unused variable `p'.
kern_thr.c: - Variable `error' is always caught immediately, so no reason to initialize it. There is no way tha
Remove even more unneeded variable assignments.
kern_time.c: - Unused variable `p'.
kern_thr.c: - Variable `error' is always caught immediately, so no reason to initialize it. There is no way that error != 0 at the end of create_thread().
kern_sig.c: - Unused variable `code'.
kern_synch.c: - `rval' is always assigned in all different cases.
kern_rwlock.c: - `v' is always overwritten with RW_UNLOCKED further on.
kern_malloc.c: - `size' is always initialized with the proper value before being used.
kern_exit.c: - `error' is always caught and returned immediately. abort2() never returns a non-zero value.
kern_exec.c: - `len' is always assigned inside the if-statement right below it.
tty_info.c: - `td' is always overwritten by FOREACH_THREAD_IN_PROC().
Found by: LLVM's scan-build
show more ...
|
Revision tags: release/7.1.0_cvs, release/7.1.0 |
|
#
e1d881ba |
| 08-Dec-2008 |
Kip Macy <kmacy@FreeBSD.org> |
add RW_SYSINIT_FLAGS macro and rw_sysinit_flags initialization function
|