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->
Just after it's allocation.
Signed-off-by: Shen Feng
---
fs/btrfs/super.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index b4c101d..4c31c4f 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -322,6 +322,11 @@ static
Hi,
I'm not sure if this patch is useful.
I developed it only for my personal using.
Make the tree name and key type output more readable.
Signed-off-by: Shen Feng
---
debug-tree.c | 72 +++-
print-tree.c | 79 +++
Now btrfsctl -a will do nothing and no error is output
if btrfs.ko is not inserted.
Since no caller do error processing for btrfs_register_one_device,
make its return void and do error processing inside.
Signed-off-by: Shen Feng
---
utils.c | 15 +++
utils.h |2 +-
2 files c
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 task
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;
> +
> +
On Tue, 6 Jan 2009, Matthew Wilcox wrote:
> >
> > This looks ugly. Why doesn't __mutex_lock_common() just set the lock
> > owner? Hate seeing it done in the caller that has to re-compute common
> > (yeah, yeah, it's cheap) and just looks ugly.
>
> Because __mutex_lock_common() is the slow pat
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;
> __mutex_fastpath_unlock(&
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_sle
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;
> +
> migh
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 f
On Tue, 2009-01-06 at 14:22 -0800, Linus Torvalds wrote:
>
> 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
On Tue, Jan 06, 2009 at 10:44:35PM +0100, Peter Zijlstra wrote:
> On Tue, 2009-01-06 at 13:42 -0800, Paul E. McKenney wrote:
> > Preemptable RCU needs to be faster. Got it -- and might have a way
> > to do it by eliminating the irq disabling and cutting way back on the
> > number of operations tha
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 wor
J. Bruce Fields wrote:
> Old kernel versions may still get booted after brtfs has gotten a
> reputation for stability. E.g. if I move my / to brtfs in 2.6.34, then
> one day need to boot back to 2.6.30 to track down some regression, the
> reminder that I'm moving back to some sort of brtfs dark-ag
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
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 y
On Tue, 2009-01-06 at 13:42 -0800, Paul E. McKenney wrote:
> Preemptable RCU needs to be faster. Got it -- and might have a way
> to do it by eliminating the irq disabling and cutting way back on the
> number of operations that must be performed. It would probably still
> be necessary to access t
On Tue, Jan 06, 2009 at 09:15:53AM -0500, Gregory Haskins wrote:
> Peter Zijlstra wrote:
> > On Tue, 2009-01-06 at 14:16 +0100, Ingo Molnar wrote:
> >
> >> * Gregory Haskins wrote:
> >>
> >>
> >>> Ingo Molnar wrote:
> >>>
> There's no time or spin-rate based heuristics in this
Hello everyone,
Thanks for all of the comments so far. I've pushed out a number of
fixes for btrfs mainline, covering most of the comments from this
thread.
* All LINUX_KERNEL_VERSION checks are gone.
* checkpatch.pl fixes
* Extra permission checks on the ioctls
* Some important bug fixes from t
>
> Btw, this also fixes a bug: your patch did
>
> + __set_task_state(task, state);
> + /* didnt get the lock, go to sleep: */
> + schedule();
>
> for the schedule case without holding the mutex spinlock.
>
> And tha
On Tue, 6 Jan 2009, Steven Rostedt wrote:
>
> Caching the rq is an interesting idea. But since the rq struct is local to
> sched.c, what would be a good API to do this?
Just move the whole "spin_or_schedule()" into sched.c, and you're all
done.
Yeah, that requires having sched.c know a bit a
On Tue, 6 Jan 2009, Linus Torvalds wrote:
>
> Sure - the owner may have rescheduled to another CPU, but if it did that,
> then we really might as well sleep.
.. or at least re-try the loop.
It might be worth it to move the whole sleeping behavior into that helper
function (mutex_spin_or_slee
On Tue, 6 Jan 2009, Linus Torvalds wrote:
>
> 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;
> >
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, Andrew Morton wrote:
> On Tue, 06 Jan 2009 12:40:31 +0100 Peter Zijlstra
> wrote:
>
> > Subject: mutex: adaptive spin
> > From: Peter Zijlstra
> > Date: Tue Jan 06 12:32:12 CET 2009
> >
> > Based on the code in -rt, provide adaptive spins on generic mutexes.
> >
>
> How
On Tuesday 06 January 2009 04:10:42 Nick Piggin wrote:
> On Tuesday 06 January 2009 03:37:33 Chris Mason wrote:
> > So, long term we can have a benchmarking contest, but I've got a little
> > ways to go before that is a good idea.
>
> That would be good.
This got me motivated to rebase fsblock to
On Tue, 06 Jan 2009 12:40:31 +0100 Peter Zijlstra wrote:
> Subject: mutex: adaptive spin
> From: Peter Zijlstra
> 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 uncommented, changelogged code as an
* Linus Torvalds 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.
>
> Clarification: the "nice back
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.
* Ingo Molnar 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 logs nor
* Linus Torvalds wrote:
> On Tue, 6 Jan 2009, Linus Torvalds wrote:
> >
> > So it should be renamed. Something like "task_is_oncpu()" or whatever.
>
> Another complaint, which is tangentially related in that it actually
> concerns "current".
>
> Right now, if some process deadlocks on a mute
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
On Tue, 6 Jan 2009, Linus Torvalds wrote:
>
> So it should be renamed. Something like "task_is_oncpu()" or whatever.
Another complaint, which is tangentially related in that it actually
concerns "current".
Right now, if some process deadlocks on a mutex, we get hung process, but
with a nice
On Tue, 6 Jan 2009, Linus Torvalds wrote:
> 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 _this_ task.
>
> So the only sensible implementation of "task_is_current(task)" i
On Tue, 2009-01-06 at 12:40 +0100, Peter Zijlstra wrote:
> Subject: mutex: adaptive spin
> From: Peter Zijlstra
> 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 without mutex
deb
On Tue, 2009-01-06 at 07:55 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Jan 2009, Ingo Molnar wrote:
> >
> > The thing i like most about Peter's patch (compared to most other adaptive
> > spinning approaches i've seen, which all sucked as they included various
> > ugly heuristics complicating th
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 ta
On Tue, 6 Jan 2009, Ingo Molnar wrote:
>
> The thing i like most about Peter's patch (compared to most other adaptive
> spinning approaches i've seen, which all sucked as they included various
> ugly heuristics complicating the whole thing) is that it solves the "how
> long should we spin" qu
On Tue, Jan 06, 2009 at 01:21:41PM +0100, Peter Zijlstra wrote:
> > It's hard to tell how it would impact inbetween workloads - i guess it
> > needs to be measured on a couple of workloads.
>
> Matthew volunteered to run something IIRC.
I've sent it off to two different teams at Intel for benchm
Hello everyone,
I'm pushing out fixes for most of the issues brought up in code review
for merging into mainline. Soon the unstable trees will be updated to
2.6.28
One of the commits is quite large, fixing almost all of the
checkpatch.pl warnings and errors. Most of them were one of these 3:
w
Peter Zijlstra wrote:
> On Tue, 2009-01-06 at 14:16 +0100, Ingo Molnar wrote:
>
>> * Gregory Haskins 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
On Tue, Jan 06, 2009 at 12:40:31PM +0100, Peter Zijlstra wrote:
> Subject: mutex: adaptive spin
> From: Peter Zijlstra
> Date: Tue Jan 06 12:32:12 CET 2009
>
> Based on the code in -rt, provide adaptive spins on generic mutexes.
I guess it would be nice to add another type so you can test/conver
On Tue, 2009-01-06 at 14:16 +0100, Ingo Molnar wrote:
> * Gregory Haskins 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 imp
* Gregory Haskins 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 implementation
> to reflect that the locks can adaptively spin or sle
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 t
On Tue, 2009-01-06 at 13:10 +0100, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > +++ linux-2.6/kernel/mutex.c
> > @@ -46,6 +46,7 @@ __mutex_init(struct mutex *lock, const c
> > atomic_set(&lock->count, 1);
> > spin_lock_init(&lock->wait_lock);
> > INIT_LIST_HEAD(&lock->wait_list)
* Peter Zijlstra wrote:
> +++ linux-2.6/kernel/mutex.c
> @@ -46,6 +46,7 @@ __mutex_init(struct mutex *lock, const c
> atomic_set(&lock->count, 1);
> spin_lock_init(&lock->wait_lock);
> INIT_LIST_HEAD(&lock->wait_list);
> + lock->owner = NULL;
>
> debug_mutex_init(lo
Subject: mutex: adaptive spin
From: Peter Zijlstra
Date: Tue Jan 06 12:32:12 CET 2009
Based on the code in -rt, provide adaptive spins on generic mutexes.
Signed-off-by: Peter Zijlstra
---
include/linux/mutex.h |4 ++--
include/linux/sched.h |1 +
kernel/mutex-debug.c | 11 ++---
49 matches
Mail list logo
