From: Peter W.Morreale [EMAIL PROTECTED]
This patch adds the adaptive spin lock busywait to rtmutexes. It adds
a new tunable: rtmutex_timeout, which is the companion to the
rtlock_timeout tunable.
Signed-off-by: Peter W. Morreale [EMAIL PROTECTED]
---
kernel/Kconfig.preempt| 37
From: Peter W.Morreale [EMAIL PROTECTED]
In wakeup_next_waiter(), we take the pi_lock, and then find out whether
we have another waiter to add to the pending owner. We can reduce
contention on the pi_lock for the pending owner if we first obtain the
pointer to the next waiter outside of the
From: Sven-Thorsten Dietrich [EMAIL PROTECTED]
Add /proc/sys/kernel/lateral_steal, to allow switching on and off
equal-priority mutex stealing between threads.
Signed-off-by: Sven-Thorsten Dietrich [EMAIL PROTECTED]
---
kernel/rtmutex.c |8 ++--
kernel/sysctl.c | 14 ++
It is redundant to wake the grantee task if it is already running
Credit goes to Peter for the general idea.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
Signed-off-by: Peter Morreale [EMAIL PROTECTED]
---
kernel/rtmutex.c | 23 ++-
1 files changed, 18 insertions(+),
From: Nick Piggin [EMAIL PROTECTED]
Introduce ticket lock spinlocks for x86 which are FIFO. The implementation
is described in the comments. The straight-line lock/unlock instruction
sequence is slightly slower than the dec based locks on modern x86 CPUs,
however the difference is quite small on
Preemptible spinlock waiters effectively bypasses the benefits of a fifo
spinlock. Since we now have fifo spinlocks for x86 enabled, disable the
preemption feature on x86.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
CC: Nick Piggin [EMAIL PROTECTED]
---
arch/x86/Kconfig |1 +
1 files
From: Sven Dietrich [EMAIL PROTECTED]
Signed-off-by: Sven Dietrich [EMAIL PROTECTED]
---
kernel/Kconfig.preempt| 11 +++
kernel/rtmutex.c |4
kernel/rtmutex_adaptive.h | 11 +--
kernel/sysctl.c | 12
4 files changed, 36
The Real Time patches to the Linux kernel converts the architecture
specific SMP-synchronization primitives commonly referred to as
spinlocks to an RT mutex implementation that support a priority
inheritance protocol, and priority-ordered wait queues. The RT mutex
implementation allows tasks that
The current logic makes rather coarse adjustments to current-state since
it is planning on sleeping anyway. We want to eventually move to an
adaptive (e.g. optional sleep) algorithm, so we tighten the scope of the
adjustments to bracket the schedule(). This should yield correct behavior
with or
The logic is currently broken so that PREEMPT_RT disables preemptible
spinlock waiters, which is counter intuitive.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/spinlock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/spinlock.c
We introduce a configuration variable for the feature to make it easier for
various architectures and/or configs to enable or disable it based on their
requirements.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/Kconfig.preempt |9 +
kernel/spinlock.c |7
On Thu, Feb 21, 2008 at 10:26 AM, in message
[EMAIL PROTECTED], Gregory Haskins
[EMAIL PROTECTED] wrote:
We have put together some data from different types of benchmarks for
this patch series, which you can find here:
ftp://ftp.novell.com/dev/ghaskins/adaptive-locks.pdf
For convenience,
On Thu, Feb 21, 2008 at 11:41 AM, in message [EMAIL PROTECTED],
Andi Kleen [EMAIL PROTECTED] wrote:
+config RTLOCK_DELAY
+int Default delay (in loops) for adaptive rtlocks
+range 0 10
+depends on ADAPTIVE_RTLOCK
I must say I'm not a big fan of putting such subtle
On Thu, 2008-02-21 at 11:48 -0500, Steven Rostedt wrote:
On Thu, 21 Feb 2008, Gregory Haskins wrote:
From: Peter W.Morreale [EMAIL PROTECTED]
In wakeup_next_waiter(), we take the pi_lock, and then find out whether
we have another waiter to add to the pending owner. We can reduce
On Thursday 21 February 2008 16:27:22 Gregory Haskins wrote:
@@ -660,12 +660,12 @@ rt_spin_lock_fastlock(struct rt_mutex *lock,
void fastcall (*slowfn)(struct rt_mutex *lock))
{
/* Temporary HACK! */
- if (!current-in_printk)
- might_sleep();
- else
On Thu, 2008-02-21 at 17:41 +0100, Andi Kleen wrote:
+config RTLOCK_DELAY
+ int Default delay (in loops) for adaptive rtlocks
+ range 0 10
+ depends on ADAPTIVE_RTLOCK
I must say I'm not a big fan of putting such subtle configurable numbers
into Kconfig. Compilation is
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already upstream in 2.6.25-rc2 and
-rt will have them automatically once we rebase to .25.
and if we take the ticket
It would also help to get the lockdep/lockstat output for those runs
so that more discussion can happen. That framework can be extended to
do all sorts of contention tracking and that is why I took implemented
it in the first place to track the viability of adaptive spins. My
initial results where
On Thu, Feb 21, 2008 at 4:24 PM, in message [EMAIL PROTECTED],
Ingo Molnar [EMAIL PROTECTED] wrote:
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already
On Thu, Feb 21, 2008 at 4:42 PM, in message [EMAIL PROTECTED],
Ingo Molnar [EMAIL PROTECTED] wrote:
* Bill Huey (hui) [EMAIL PROTECTED] wrote:
I came to the original conclusion that it wasn't originally worth it,
but the dbench number published say otherwise. [...]
dbench is a
On Thu, 2008-02-21 at 22:24 +0100, Ingo Molnar wrote:
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already upstream in 2.6.25-rc2 and
-rt will have them
On Thu, 2008-02-21 at 15:12 -0700, Peter W. Morreale wrote:
True, the ticket spinlock certainly adds to the throughput results we
have seen. However, the results without the ticket patch are still very
significant. (IIRC, 500-600MB/s instead of the ~730MB/s advertised) We
can easily re-gen
On Thu, Feb 21, 2008 at 1:42 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
I'd not exclude them fundamentally though, it's really the numbers that
matter. The code is certainly simple enough (albeit the .config and
sysctl controls are quite ugly and unacceptable - adaptive mutexes
should really
We are pleased to announce the 2.6.24.2-rt2 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
Changes since 2.6.24-rt1
- ported to 2.6.24.2
- *** New ftrace
24 matches
Mail list logo
