Re: [(RT RFC) PATCH v2 7/9] adaptive mutexes
>>> On Mon, Feb 25, 2008 at 5:09 PM, in message
<[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> 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]>
>
> Not signed off by you?
I wasn't sure if this was appropriate for me to do. This is the first time I
was acting as "upstream" to someone. If that is what I am expected to do,
consider this an "ack" for your remaining comments related to this.
>
>> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
>> index ac1cbad..864bf14 100644
>> --- a/kernel/Kconfig.preempt
>> +++ b/kernel/Kconfig.preempt
>> @@ -214,6 +214,43 @@ config RTLOCK_DELAY
>> tunable at runtime via a sysctl. A setting of 0 (zero) disables
>> the adaptive algorithm entirely.
>>
>> +config ADAPTIVE_RTMUTEX
>> +bool "Adaptive real-time mutexes"
>> +default y
>> +depends on ADAPTIVE_RTLOCK
>> +help
>> + This option adds the adaptive rtlock spin/sleep algorithm to
>> + rtmutexes. In rtlocks, a significant gain in throughput
>> + can be seen by allowing rtlocks to spin for a distinct
>> + amount of time prior to going to sleep for deadlock avoidence.
>> +
>> + Typically, mutexes are used when a critical section may need to
>> + sleep due to a blocking operation. In the event the critical
>> + section does not need to sleep, an additional gain in throughput
>> + can be seen by avoiding the extra overhead of sleeping.
>
> Watch the whitespace. ... and do we need yet another config options?
>
>> +config RTMUTEX_DELAY
>> +int "Default delay (in loops) for adaptive mutexes"
>> +range 0 1000
>> +depends on ADAPTIVE_RTMUTEX
>> +default "3000"
>> +help
>> + This allows you to specify the maximum delay a task will use
>> + to wait for a rt mutex before going to sleep. Note that that
>> + although the delay is implemented as a preemptable loop, tasks
>> + of like priority cannot preempt each other and this setting can
>> + result in increased latencies.
>> +
>> + The value is tunable at runtime via a sysctl. A setting of 0
>> + (zero) disables the adaptive algorithm entirely.
>
> Ouch.
? Is this reference to whitespace damage, or does the content need addressing?
>
>> +#ifdef CONFIG_ADAPTIVE_RTMUTEX
>> +
>> +#define mutex_adaptive_wait adaptive_wait
>> +#define mutex_prepare_adaptive_wait prepare_adaptive_wait
>> +
>> +extern int rtmutex_timeout;
>> +
>> +#define DECLARE_ADAPTIVE_MUTEX_WAITER(name) \
>> + struct adaptive_waiter name = { .owner = NULL, \
>> + .timeout = rtmutex_timeout, }
>> +
>> +#else
>> +
>> +#define DECLARE_ADAPTIVE_MUTEX_WAITER(name)
>> +
>> +#define mutex_adaptive_wait(lock, intr, waiter, busy) 1
>> +#define mutex_prepare_adaptive_wait(lock, busy) {}
>
> More evil macros. Macro does not behave like a function, make it
> inline function if you are replacing a function.
Ok
> Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [(RT RFC) PATCH v2 7/9] adaptive mutexes
Hi!
> 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]>
Not signed off by you?
> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> index ac1cbad..864bf14 100644
> --- a/kernel/Kconfig.preempt
> +++ b/kernel/Kconfig.preempt
> @@ -214,6 +214,43 @@ config RTLOCK_DELAY
>tunable at runtime via a sysctl. A setting of 0 (zero) disables
>the adaptive algorithm entirely.
>
> +config ADAPTIVE_RTMUTEX
> +bool "Adaptive real-time mutexes"
> +default y
> +depends on ADAPTIVE_RTLOCK
> +help
> + This option adds the adaptive rtlock spin/sleep algorithm to
> + rtmutexes. In rtlocks, a significant gain in throughput
> + can be seen by allowing rtlocks to spin for a distinct
> + amount of time prior to going to sleep for deadlock avoidence.
> +
> + Typically, mutexes are used when a critical section may need to
> + sleep due to a blocking operation. In the event the critical
> + section does not need to sleep, an additional gain in throughput
> + can be seen by avoiding the extra overhead of sleeping.
Watch the whitespace. ... and do we need yet another config options?
> +config RTMUTEX_DELAY
> +int "Default delay (in loops) for adaptive mutexes"
> +range 0 1000
> +depends on ADAPTIVE_RTMUTEX
> +default "3000"
> +help
> + This allows you to specify the maximum delay a task will use
> + to wait for a rt mutex before going to sleep. Note that that
> + although the delay is implemented as a preemptable loop, tasks
> + of like priority cannot preempt each other and this setting can
> + result in increased latencies.
> +
> + The value is tunable at runtime via a sysctl. A setting of 0
> + (zero) disables the adaptive algorithm entirely.
Ouch.
> +#ifdef CONFIG_ADAPTIVE_RTMUTEX
> +
> +#define mutex_adaptive_wait adaptive_wait
> +#define mutex_prepare_adaptive_wait prepare_adaptive_wait
> +
> +extern int rtmutex_timeout;
> +
> +#define DECLARE_ADAPTIVE_MUTEX_WAITER(name) \
> + struct adaptive_waiter name = { .owner = NULL, \
> + .timeout = rtmutex_timeout, }
> +
> +#else
> +
> +#define DECLARE_ADAPTIVE_MUTEX_WAITER(name)
> +
> +#define mutex_adaptive_wait(lock, intr, waiter, busy) 1
> +#define mutex_prepare_adaptive_wait(lock, busy) {}
More evil macros. Macro does not behave like a function, make it
inline function if you are replacing a function.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[(RT RFC) PATCH v2 7/9] adaptive mutexes
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 ++
kernel/rtmutex.c | 76 +
kernel/rtmutex_adaptive.h | 32 ++-
kernel/sysctl.c | 10 ++
4 files changed, 119 insertions(+), 36 deletions(-)
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index ac1cbad..864bf14 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -214,6 +214,43 @@ config RTLOCK_DELAY
tunable at runtime via a sysctl. A setting of 0 (zero) disables
the adaptive algorithm entirely.
+config ADAPTIVE_RTMUTEX
+bool "Adaptive real-time mutexes"
+default y
+depends on ADAPTIVE_RTLOCK
+help
+ This option adds the adaptive rtlock spin/sleep algorithm to
+ rtmutexes. In rtlocks, a significant gain in throughput
+ can be seen by allowing rtlocks to spin for a distinct
+ amount of time prior to going to sleep for deadlock avoidence.
+
+ Typically, mutexes are used when a critical section may need to
+ sleep due to a blocking operation. In the event the critical
+section does not need to sleep, an additional gain in throughput
+can be seen by avoiding the extra overhead of sleeping.
+
+ This option alters the rtmutex code to use an adaptive
+ spin/sleep algorithm. It will spin unless it determines it must
+ sleep to avoid deadlock. This offers a best of both worlds
+ solution since we achieve both high-throughput and low-latency.
+
+ If unsure, say Y
+
+config RTMUTEX_DELAY
+int "Default delay (in loops) for adaptive mutexes"
+range 0 1000
+depends on ADAPTIVE_RTMUTEX
+default "3000"
+help
+ This allows you to specify the maximum delay a task will use
+to wait for a rt mutex before going to sleep. Note that that
+although the delay is implemented as a preemptable loop, tasks
+of like priority cannot preempt each other and this setting can
+result in increased latencies.
+
+ The value is tunable at runtime via a sysctl. A setting of 0
+(zero) disables the adaptive algorithm entirely.
+
config SPINLOCK_BKL
bool "Old-Style Big Kernel Lock"
depends on (PREEMPT || SMP) && !PREEMPT_RT
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 4a16b13..ea593e0 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -29,6 +29,10 @@ int rtmutex_lateral_steal __read_mostly = 1;
int rtlock_timeout __read_mostly = CONFIG_RTLOCK_DELAY;
#endif
+#ifdef CONFIG_ADAPTIVE_RTMUTEX
+int rtmutex_timeout __read_mostly = CONFIG_RTMUTEX_DELAY;
+#endif
+
/*
* lock->owner state tracking:
*
@@ -542,34 +546,33 @@ static void wakeup_next_waiter(struct rt_mutex *lock, int
savestate)
* Do the wakeup before the ownership change to give any spinning
* waiter grantees a headstart over the other threads that will
* trigger once owner changes.
+*
+* We can skip the actual (expensive) wakeup if the
+* waiter is already running, but we have to be careful
+* of race conditions because they may be about to sleep.
+*
+* The waiter-side protocol has the following pattern:
+* 1: Set state != RUNNING
+* 2: Conditionally sleep if waiter->task != NULL;
+*
+* And the owner-side has the following:
+* A: Set waiter->task = NULL
+* B: Conditionally wake if the state != RUNNING
+*
+* As long as we ensure 1->2 order, and A->B order, we
+* will never miss a wakeup.
+*
+* Therefore, this barrier ensures that waiter->task = NULL
+* is visible before we test the pendowner->state. The
+* corresponding barrier is in the sleep logic.
*/
- if (!savestate)
- wake_up_process(pendowner);
- else {
- /*
-* We can skip the actual (expensive) wakeup if the
-* waiter is already running, but we have to be careful
-* of race conditions because they may be about to sleep.
-*
-* The waiter-side protocol has the following pattern:
-* 1: Set state != RUNNING
-* 2: Conditionally sleep if waiter->task != NULL;
-*
-* And the owner-side has the following:
-* A: Set waiter->task = NULL
-* B: Conditionally wake if the state != RUNNING
-*
-* As long as we ensure 1->2 order, and A->B order, we
-* will never miss a
[(RT RFC) PATCH v2 7/9] adaptive mutexes
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 ++
kernel/rtmutex.c | 76 +
kernel/rtmutex_adaptive.h | 32 ++-
kernel/sysctl.c | 10 ++
4 files changed, 119 insertions(+), 36 deletions(-)
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index ac1cbad..864bf14 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -214,6 +214,43 @@ config RTLOCK_DELAY
tunable at runtime via a sysctl. A setting of 0 (zero) disables
the adaptive algorithm entirely.
+config ADAPTIVE_RTMUTEX
+bool Adaptive real-time mutexes
+default y
+depends on ADAPTIVE_RTLOCK
+help
+ This option adds the adaptive rtlock spin/sleep algorithm to
+ rtmutexes. In rtlocks, a significant gain in throughput
+ can be seen by allowing rtlocks to spin for a distinct
+ amount of time prior to going to sleep for deadlock avoidence.
+
+ Typically, mutexes are used when a critical section may need to
+ sleep due to a blocking operation. In the event the critical
+section does not need to sleep, an additional gain in throughput
+can be seen by avoiding the extra overhead of sleeping.
+
+ This option alters the rtmutex code to use an adaptive
+ spin/sleep algorithm. It will spin unless it determines it must
+ sleep to avoid deadlock. This offers a best of both worlds
+ solution since we achieve both high-throughput and low-latency.
+
+ If unsure, say Y
+
+config RTMUTEX_DELAY
+int Default delay (in loops) for adaptive mutexes
+range 0 1000
+depends on ADAPTIVE_RTMUTEX
+default 3000
+help
+ This allows you to specify the maximum delay a task will use
+to wait for a rt mutex before going to sleep. Note that that
+although the delay is implemented as a preemptable loop, tasks
+of like priority cannot preempt each other and this setting can
+result in increased latencies.
+
+ The value is tunable at runtime via a sysctl. A setting of 0
+(zero) disables the adaptive algorithm entirely.
+
config SPINLOCK_BKL
bool Old-Style Big Kernel Lock
depends on (PREEMPT || SMP) !PREEMPT_RT
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 4a16b13..ea593e0 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -29,6 +29,10 @@ int rtmutex_lateral_steal __read_mostly = 1;
int rtlock_timeout __read_mostly = CONFIG_RTLOCK_DELAY;
#endif
+#ifdef CONFIG_ADAPTIVE_RTMUTEX
+int rtmutex_timeout __read_mostly = CONFIG_RTMUTEX_DELAY;
+#endif
+
/*
* lock-owner state tracking:
*
@@ -542,34 +546,33 @@ static void wakeup_next_waiter(struct rt_mutex *lock, int
savestate)
* Do the wakeup before the ownership change to give any spinning
* waiter grantees a headstart over the other threads that will
* trigger once owner changes.
+*
+* We can skip the actual (expensive) wakeup if the
+* waiter is already running, but we have to be careful
+* of race conditions because they may be about to sleep.
+*
+* The waiter-side protocol has the following pattern:
+* 1: Set state != RUNNING
+* 2: Conditionally sleep if waiter-task != NULL;
+*
+* And the owner-side has the following:
+* A: Set waiter-task = NULL
+* B: Conditionally wake if the state != RUNNING
+*
+* As long as we ensure 1-2 order, and A-B order, we
+* will never miss a wakeup.
+*
+* Therefore, this barrier ensures that waiter-task = NULL
+* is visible before we test the pendowner-state. The
+* corresponding barrier is in the sleep logic.
*/
- if (!savestate)
- wake_up_process(pendowner);
- else {
- /*
-* We can skip the actual (expensive) wakeup if the
-* waiter is already running, but we have to be careful
-* of race conditions because they may be about to sleep.
-*
-* The waiter-side protocol has the following pattern:
-* 1: Set state != RUNNING
-* 2: Conditionally sleep if waiter-task != NULL;
-*
-* And the owner-side has the following:
-* A: Set waiter-task = NULL
-* B: Conditionally wake if the state != RUNNING
-*
-* As long as we ensure 1-2 order, and A-B order, we
-* will never miss a wakeup.
-*
-
Re: [(RT RFC) PATCH v2 7/9] adaptive mutexes
Hi!
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]
Not signed off by you?
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index ac1cbad..864bf14 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -214,6 +214,43 @@ config RTLOCK_DELAY
tunable at runtime via a sysctl. A setting of 0 (zero) disables
the adaptive algorithm entirely.
+config ADAPTIVE_RTMUTEX
+bool Adaptive real-time mutexes
+default y
+depends on ADAPTIVE_RTLOCK
+help
+ This option adds the adaptive rtlock spin/sleep algorithm to
+ rtmutexes. In rtlocks, a significant gain in throughput
+ can be seen by allowing rtlocks to spin for a distinct
+ amount of time prior to going to sleep for deadlock avoidence.
+
+ Typically, mutexes are used when a critical section may need to
+ sleep due to a blocking operation. In the event the critical
+ section does not need to sleep, an additional gain in throughput
+ can be seen by avoiding the extra overhead of sleeping.
Watch the whitespace. ... and do we need yet another config options?
+config RTMUTEX_DELAY
+int Default delay (in loops) for adaptive mutexes
+range 0 1000
+depends on ADAPTIVE_RTMUTEX
+default 3000
+help
+ This allows you to specify the maximum delay a task will use
+ to wait for a rt mutex before going to sleep. Note that that
+ although the delay is implemented as a preemptable loop, tasks
+ of like priority cannot preempt each other and this setting can
+ result in increased latencies.
+
+ The value is tunable at runtime via a sysctl. A setting of 0
+ (zero) disables the adaptive algorithm entirely.
Ouch.
+#ifdef CONFIG_ADAPTIVE_RTMUTEX
+
+#define mutex_adaptive_wait adaptive_wait
+#define mutex_prepare_adaptive_wait prepare_adaptive_wait
+
+extern int rtmutex_timeout;
+
+#define DECLARE_ADAPTIVE_MUTEX_WAITER(name) \
+ struct adaptive_waiter name = { .owner = NULL, \
+ .timeout = rtmutex_timeout, }
+
+#else
+
+#define DECLARE_ADAPTIVE_MUTEX_WAITER(name)
+
+#define mutex_adaptive_wait(lock, intr, waiter, busy) 1
+#define mutex_prepare_adaptive_wait(lock, busy) {}
More evil macros. Macro does not behave like a function, make it
inline function if you are replacing a function.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [(RT RFC) PATCH v2 7/9] adaptive mutexes
On Mon, Feb 25, 2008 at 5:09 PM, in message
[EMAIL PROTECTED], Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
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]
Not signed off by you?
I wasn't sure if this was appropriate for me to do. This is the first time I
was acting as upstream to someone. If that is what I am expected to do,
consider this an ack for your remaining comments related to this.
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index ac1cbad..864bf14 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -214,6 +214,43 @@ config RTLOCK_DELAY
tunable at runtime via a sysctl. A setting of 0 (zero) disables
the adaptive algorithm entirely.
+config ADAPTIVE_RTMUTEX
+bool Adaptive real-time mutexes
+default y
+depends on ADAPTIVE_RTLOCK
+help
+ This option adds the adaptive rtlock spin/sleep algorithm to
+ rtmutexes. In rtlocks, a significant gain in throughput
+ can be seen by allowing rtlocks to spin for a distinct
+ amount of time prior to going to sleep for deadlock avoidence.
+
+ Typically, mutexes are used when a critical section may need to
+ sleep due to a blocking operation. In the event the critical
+ section does not need to sleep, an additional gain in throughput
+ can be seen by avoiding the extra overhead of sleeping.
Watch the whitespace. ... and do we need yet another config options?
+config RTMUTEX_DELAY
+int Default delay (in loops) for adaptive mutexes
+range 0 1000
+depends on ADAPTIVE_RTMUTEX
+default 3000
+help
+ This allows you to specify the maximum delay a task will use
+ to wait for a rt mutex before going to sleep. Note that that
+ although the delay is implemented as a preemptable loop, tasks
+ of like priority cannot preempt each other and this setting can
+ result in increased latencies.
+
+ The value is tunable at runtime via a sysctl. A setting of 0
+ (zero) disables the adaptive algorithm entirely.
Ouch.
? Is this reference to whitespace damage, or does the content need addressing?
+#ifdef CONFIG_ADAPTIVE_RTMUTEX
+
+#define mutex_adaptive_wait adaptive_wait
+#define mutex_prepare_adaptive_wait prepare_adaptive_wait
+
+extern int rtmutex_timeout;
+
+#define DECLARE_ADAPTIVE_MUTEX_WAITER(name) \
+ struct adaptive_waiter name = { .owner = NULL, \
+ .timeout = rtmutex_timeout, }
+
+#else
+
+#define DECLARE_ADAPTIVE_MUTEX_WAITER(name)
+
+#define mutex_adaptive_wait(lock, intr, waiter, busy) 1
+#define mutex_prepare_adaptive_wait(lock, busy) {}
More evil macros. Macro does not behave like a function, make it
inline function if you are replacing a function.
Ok
Pavel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
