On Fri, 22 Feb 2008, Gregory Haskins wrote:
Gregory Haskins wrote:
@@ -732,14 +741,15 @@ rt_spin_lock_slowlock(struct rt_mutex *lock)
debug_rt_mutex_print_deadlock(waiter);
- schedule_rt_mutex(lock);
+ update_current(TASK_UNINTERRUPTIBLE,
On Thu, Feb 21, 2008 at 05:41:09PM +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.
On Fri, Feb 22, 2008 at 11:08 AM, Paul E. McKenney
[EMAIL PROTECTED] wrote:
One approach would be to set the RTLOCK_DELAY parameter to something like
-1 for default, and to set it to the number of cycles required for about
10 cache misses at boot time. This would automatically scale with
On Fri, Feb 22, 2008 at 11:19 AM, Bill Huey (hui) [EMAIL PROTECTED] wrote:
Yeah, I'm not very keen on having a constant there without some
contention instrumentation to see how long the spins are. It would be
better to just let it run until either task-on_cpu is off or checking
if the
Hi!
Decorate the printk path with an unlikely()
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/rtmutex.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 122f143..ebdaa17 100644
---
Hi!
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
On Fri, Feb 22, 2008 at 11:55:45AM -0800, Sven-Thorsten Dietrich wrote:
On Fri, 2008-02-22 at 11:43 -0800, Paul E. McKenney wrote:
On Fri, Feb 22, 2008 at 11:21:14AM -0800, Bill Huey (hui) wrote:
On Fri, Feb 22, 2008 at 11:19 AM, Bill Huey (hui) [EMAIL PROTECTED]
wrote:
Yeah, I'm
Paul E. McKenney wrote:
Governing the timeout by context-switch overhead sounds even better to me.
Really easy to calibrate, and short critical sections are of much shorter
duration than are a context-switch pair.
Yeah, fully agree. This is on my research todo list. My theory is
that the
Pavel Machek wrote:
Hi!
Decorate the printk path with an unlikely()
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/rtmutex.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 122f143..ebdaa17 100644
---
On Fri, Feb 22, 2008 at 2:20 PM, Gregory Haskins
[EMAIL PROTECTED] wrote:
Agreed, but it's still correct afaict. I added an extra might_sleep()
to a path that really might sleep. I should have mentioned that in the
header.
In any case, its moot. Andi indicated this patch is probably a
On Fri, 2008-02-22 at 13:36 -0700, Peter W. Morreale wrote:
On Fri, 2008-02-22 at 11:55 -0800, Sven-Thorsten Dietrich wrote:
In high-contention, short-hold time situations, it may even make sense
to have multiple CPUs with multiple waiters spinning, depending on
hold-time vs. time to
11 matches
Mail list logo
