On Wed, Jan 07, 2009 at 03:34:47PM +0800, Lai Jiangshan wrote:
So I think current task should sleep earlier when it detects that
mutex owner start schedule().
How do you propose it detects this?
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we
Ingo Molnar wrote:
There's no time or spin-rate based heuristics in this at all (i.e. these
mutexes are not 'adaptive' at all!),
FYI: The original adaptive name was chosen in the -rt implementation
to reflect that the locks can adaptively spin or sleep, depending on
conditions. I realize this
On Tue, 2009-01-06 at 14:16 +0100, Ingo Molnar wrote:
* Gregory Haskins ghask...@novell.com wrote:
Ingo Molnar wrote:
There's no time or spin-rate based heuristics in this at all (i.e. these
mutexes are not 'adaptive' at all!),
FYI: The original adaptive name was chosen in the -rt
Peter Zijlstra wrote:
On Tue, 2009-01-06 at 14:16 +0100, Ingo Molnar wrote:
* Gregory Haskins ghask...@novell.com wrote:
Ingo Molnar wrote:
There's no time or spin-rate based heuristics in this at all (i.e. these
mutexes are not 'adaptive' at all!),
FYI: The
On Tue, 6 Jan 2009, Linus Torvalds wrote:
The other way around, you mean: we spin until the owner is no longer
holding a cpu.
Btw, I hate the name of the helper function for that. task_is_current()?
current means something totally different in the linux kernel: it means
that the task is
On Tue, 2009-01-06 at 12:40 +0100, Peter Zijlstra wrote:
Subject: mutex: adaptive spin
From: Peter Zijlstra a.p.zijls...@chello.nl
Date: Tue Jan 06 12:32:12 CET 2009
Based on the code in -rt, provide adaptive spins on generic mutexes.
I already sent Peter details, but the patch has problems
On Tue, 6 Jan 2009, Linus Torvalds wrote:
Right now, if some process deadlocks on a mutex, we get hung process, but
with a nice backtrace and hopefully other things (that don't need that
lock) still continue to work.
Clarification: the nice backtrace we only get with something like
* Ingo Molnar mi...@elte.hu wrote:
One thought:
BUG_ON()'s do_exit() shows a slightly misleading failure pattern to
users: instead of a 'hanging' task, we'd get a misbehaving app due to
one of its tasks exiting spuriously. It can even go completely unnoticed
[users dont look at kernel
On Tue, 6 Jan 2009, Ingo Molnar wrote:
So instead of the BUG_ON() we could emit a WARN_ONCE() perhaps, plus not
do any spinning and just block - resulting in an uninterruptible task
(that the user will probably notice) and a scary message in the syslog?
[all in the slowpath]
Sure. You
* Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, 6 Jan 2009, Linus Torvalds wrote:
Right now, if some process deadlocks on a mutex, we get hung process,
but with a nice backtrace and hopefully other things (that don't need
that lock) still continue to work.
On Tue, 06 Jan 2009 12:40:31 +0100 Peter Zijlstra pet...@infradead.org wrote:
Subject: mutex: adaptive spin
From: Peter Zijlstra a.p.zijls...@chello.nl
Date: Tue Jan 06 12:32:12 CET 2009
Based on the code in -rt, provide adaptive spins on generic mutexes.
How dumb is it to send a lump of
Ok, last comment, I promise.
On Tue, 6 Jan 2009, Peter Zijlstra wrote:
@@ -175,11 +199,19 @@ __mutex_lock_common(struct mutex *lock,
debug_mutex_free_waiter(waiter);
return -EINTR;
}
- __set_task_state(task, state);
On Tue, 6 Jan 2009, Peter Zijlstra wrote:
With Linus' mutex_spin_or_schedule() function the whole - keeping
owner's task_struct alive issue goes away,.. now if only the thing would
boot...
Can you post the patch, so that we can see if we can find some silly error
that we can ridicule you
On Tue, 2009-01-06 at 13:50 -0800, Linus Torvalds wrote:
On Tue, 6 Jan 2009, Peter Zijlstra wrote:
With Linus' mutex_spin_or_schedule() function the whole - keeping
owner's task_struct alive issue goes away,.. now if only the thing would
boot...
Can you post the patch, so that we
On Tue, 6 Jan 2009, Peter Zijlstra wrote:
One of the things the previous patch did wrong was that it never tracked
the owner in the mutex fast path -- I initially didn't notice because I
had all debugging infrastructure enabled, and that short circuits all
the fast paths.
Why even worry?
On Tue, 6 Jan 2009, Peter Zijlstra wrote:
In fact, I suspect that's the real bug you're hitting: you're enabling
preemption while holding a spinlock. That is NOT a good idea.
spinlocks also fiddle with preempt_count, that should all work out -
although granted, it does look funny.
On Tue, 6 Jan 2009, Peter Zijlstra wrote:
Indeed, the below does boot -- which means I get to sleep now ;-)
Well, if you didn't go to sleep, a few more questions..
int __sched
mutex_lock_killable_nested(struct mutex *lock, unsigned int subclass)
{
+ int ret;
+
On Tue, Jan 06, 2009 at 03:00:47PM -0800, Linus Torvalds wrote:
Well, if you didn't go to sleep, a few more questions..
I know this one! Me sir, me me me!
int __sched
mutex_lock_killable_nested(struct mutex *lock, unsigned int subclass)
{
+ int ret;
+
might_sleep();
-
On Tue, 2009-01-06 at 23:43 +0100, Peter Zijlstra wrote:
@@ -115,6 +117,7 @@ void __sched mutex_unlock(struct mutex *
* The unlocking fastpath is the 0-1 transition from 'locked'
* into 'unlocked' state:
*/
+ lock-owner = NULL;
Peter Zijlstra wrote:
+void mutex_spin_or_schedule(struct mutex_waiter *waiter, long state,
unsigned long *flags)
+{
+ struct mutex *lock = waiter-lock;
+ struct task_struct *task = waiter-task;
+ struct task_struct *owner = lock-owner;
+ struct rq *rq;
+
+ if
Peter Zijlstra wrote:
On Wed, 2009-01-07 at 11:57 +0800, Lai Jiangshan wrote:
Peter Zijlstra wrote:
+void mutex_spin_or_schedule(struct mutex_waiter *waiter, long state,
unsigned long *flags)
+{
+ struct mutex *lock = waiter-lock;
+ struct task_struct *task = waiter-task;
+ struct
21 matches
Mail list logo
