History log of /freebsd/sys/kern/kern_rwlock.c (Results 226 – 250 of 299)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# ddb38a1f 07-Mar-2007 John Baldwin <jhb@FreeBSD.org>

Fix some nits in lock profiling for rwlocks:
- Properly note when a read lock is released.
- Always note when we contest on a read lock.
- Only note success of obtaining read locks for the first read

Fix some nits in lock profiling for rwlocks:
- Properly note when a read lock is released.
- Always note when we contest on a read lock.
- Only note success of obtaining read locks for the first reader to match
the behavior of sx(9).

Reviewed by: kmacy

show more ...


# f183910b 27-Feb-2007 Kip Macy <kmacy@FreeBSD.org>

Further improvements to LOCK_PROFILING:
- Fix missing initialization in kern_rwlock.c causing bogus times to be collected
- Move updates to the lock hash to after the lock is released for spin mute

Further improvements to LOCK_PROFILING:
- Fix missing initialization in kern_rwlock.c causing bogus times to be collected
- Move updates to the lock hash to after the lock is released for spin mutexes,
sleep mutexes, and sx locks
- Add new kernel build option LOCK_PROFILE_FAST - only update lock profiling
statistics when an acquisition is contended. This reduces the overhead of
LOCK_PROFILING to increasing system time by 20%-25% which on
"make -j8 kernel-toolchain" on a dual woodcrest is unmeasurable in terms
of wall-clock time. Contrast this to enabling lock profiling without
LOCK_PROFILE_FAST and I see a 5x-6x slowdown in wall-clock time.

show more ...


# 8525230a 26-Feb-2007 Robert Watson <rwatson@FreeBSD.org>

Add rw_wowned() interface to rwlock(9), allowing a kernel thread to
determine if it holds an exclusive rwlock reference or not. This is
non-ideal, but recursion scenarios in the network stack curren

Add rw_wowned() interface to rwlock(9), allowing a kernel thread to
determine if it holds an exclusive rwlock reference or not. This is
non-ideal, but recursion scenarios in the network stack currently
require it.

Approved by: jhb

show more ...


# fe68a916 26-Feb-2007 Kip Macy <kmacy@FreeBSD.org>

general LOCK_PROFILING cleanup

- only collect timestamps when a lock is contested - this reduces the overhead
of collecting profiles from 20x to 5x

- remove unused function from subr_lock.c

- ge

general LOCK_PROFILING cleanup

- only collect timestamps when a lock is contested - this reduces the overhead
of collecting profiles from 20x to 5x

- remove unused function from subr_lock.c

- generalize cnt_hold and cnt_lock statistics to be kept for all locks

- NOTE: rwlock profiling generates invalid statistics (and most likely always has)
someone familiar with that should review

show more ...


Revision tags: release/6.2.0_cvs, release/6.2.0
# 61bd5e21 13-Nov-2006 Kip Macy <kmacy@FreeBSD.org>

track lock class name in a way that doesn't break WITNESS


# 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 ...


# 764e4d54 27-Jul-2006 John Baldwin <jhb@FreeBSD.org>

Adjust td_locks for non-spin mutexes, rwlocks, and sx locks so that it is
a count of all non-spin locks, not just lockmgr locks. This can give us a
much cheaper way to see if we have any locks held

Adjust td_locks for non-spin mutexes, rwlocks, and sx locks so that it is
a count of all non-spin locks, not just lockmgr locks. This can give us a
much cheaper way to see if we have any locks held (such as when returning
to userland via userret()) without requiring WITNESS.

MFC after: 1 week

show more ...


Revision tags: release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0
# fea3efe5 19-Apr-2006 John Baldwin <jhb@FreeBSD.org>

Implement rw_try_upgrade() and rw_downgrade(). rw_try_upgrade() makes a
single attempt at upgrading a read lock to a write lock, and rw_downgrade()
converts curthread's write lock into a read lock.


# 5884c1a0 18-Apr-2006 Wojciech A. Koszek <wkoszek@FreeBSD.org>

'owner' is not used without SMP. Fix kernel build for such kernel
configurations.

Approved by: jhb


# efa86db6 18-Apr-2006 John Baldwin <jhb@FreeBSD.org>

Adaptively spin before blocking on the turnstile if an rwlock is write
locked. In general the adaptive spinning is similar to the same code
for mutexes with some extra trickiness in rw_wunlock_hard(

Adaptively spin before blocking on the turnstile if an rwlock is write
locked. In general the adaptive spinning is similar to the same code
for mutexes with some extra trickiness in rw_wunlock_hard(). Specifically,
even though both wait bits might be set and we might have a turnstile with
at least one waiting thread, there might not be any threads blocked on the
queue we are not waking up (they might all be spinning), and we should
only preserve the waiting flag for the queue we aren't waking up if there
are in fact threads blocked on that queue. Secondly, there might not be
any threads blocked on the queue we have chosen to waken threads from
(there might only be threads blocked on the other queue and the threads
for this queue are all spinning) in which case we disown the turnstile
instead of doing a braodcast and unpend.

show more ...


# 38bf165f 17-Apr-2006 John Baldwin <jhb@FreeBSD.org>

- Add a rw_wowner() macro that just returns the owner of a write lock and
use it in places that only care about the write owner instead of
rw_owner() as a baby step towards limited read-lock owne

- Add a rw_wowner() macro that just returns the owner of a write lock and
use it in places that only care about the write owner instead of
rw_owner() as a baby step towards limited read-lock owner.
- Tidy the code that sets the WAITER flag bits to not duplicate a test
around the atomic operation and the KTR trace in both of the lock
functions.

show more ...


# 803e980d 01-Feb-2006 Scott Long <scottl@FreeBSD.org>

Fix another compile problem. If I find any more, this file is going in the
Attic until it is properly fixed.


# 019a2f40 30-Jan-2006 Scott Long <scottl@FreeBSD.org>

Regroup order of operations to better reflect what was probably intended.

Submitted by: Peter Jeremy


# 8ad6b7ab 29-Jan-2006 Scott Long <scottl@FreeBSD.org>

Take a stab at making this compile when WITNESS is not defined. gcc can't
figure out the order of operations at line 519, and neither can I, but this
is my best guess. Also correct a number of typo

Take a stab at making this compile when WITNESS is not defined. gcc can't
figure out the order of operations at line 519, and neither can I, but this
is my best guess. Also correct a number of typos and syntax errors.

show more ...


# 69e99c5d 29-Jan-2006 Max Laier <mlaier@FreeBSD.org>

Unbreak on archs where %d doesn't print uintptr_t arithmetic.


# 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 ...


# 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 ...


# 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 ...


# cbd59a4f 08-Sep-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC from head@196987


# 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 ...


# 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


12345678910>>...12