Ingo,
This patch contains my previous change as well as an update to fix the
race conditions that the BKL may hold. It is against -rt2.
The first part of the patch will stop the pi_setprio loop if the process
has a lock_depth greater than or equal to zero. Since that would mean
that the
On Tue, 2005-08-30 at 11:00 -0400, Steven Rostedt wrote:
> OK, I'm looking for a second set of eyes (or third or more :-) to see if
> there's a danger of a deadlock here.
Unless someone sees a problem with the patch, here it is. I noticed
that I unlocked the lock->wait_lock when I should not
OK, I'm looking for a second set of eyes (or third or more :-) to see if
there's a danger of a deadlock here.
The task->pi_lock is dependent on the order of locking, which I said was
proven to be true, otherwise there would be a deadlock.
L1->P1->L2->P2-L3->P3
Where lock L1 is owned by P1
OK, I'm looking for a second set of eyes (or third or more :-) to see if
there's a danger of a deadlock here.
The task-pi_lock is dependent on the order of locking, which I said was
proven to be true, otherwise there would be a deadlock.
L1-P1-L2-P2-L3-P3
Where lock L1 is owned by P1 which is
On Tue, 2005-08-30 at 11:00 -0400, Steven Rostedt wrote:
OK, I'm looking for a second set of eyes (or third or more :-) to see if
there's a danger of a deadlock here.
Unless someone sees a problem with the patch, here it is. I noticed
that I unlocked the lock-wait_lock when I should not have.
Ingo,
This patch contains my previous change as well as an update to fix the
race conditions that the BKL may hold. It is against -rt2.
The first part of the patch will stop the pi_setprio loop if the process
has a lock_depth greater than or equal to zero. Since that would mean
that the
Ingo,
The following code segment from pick_new_owner:
waiter = plist_first_entry(>wait_list, struct rt_mutex_waiter,
list);
try_again:
trace_special_pid(waiter->ti->task->pid, waiter->ti->task->prio, 0);
#ifdef ALL_TASKS_PI
check_pi_list_present(lock, waiter,
Ingo,
The following code segment from pick_new_owner:
waiter = plist_first_entry(lock-wait_list, struct rt_mutex_waiter,
list);
try_again:
trace_special_pid(waiter-ti-task-pid, waiter-ti-task-prio, 0);
#ifdef ALL_TASKS_PI
check_pi_list_present(lock, waiter,
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
> A word of caution (aka. disclaimer). This is still new. I still expect
> there are some cases in the code that was missed and can cause a dead
> lock or other bad side effect. Hopefully, we can iron these all out.
> Also, I noticed that
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
> A word of caution (aka. disclaimer). This is still new. I still expect
> there are some cases in the code that was missed and can cause a dead
> lock or other bad side effect. Hopefully, we can iron these all out.
> Also, I noticed that
On Thu, 2005-08-25 at 19:47 +0200, Ingo Molnar wrote:
> your patch works great here, on 3 separate systems: a 1-way, a 2/4-way
> and an 8-way.
>
> the 1-way system performed so well running the SMP kernel that i first
> thought i booted the UP kernel by accident :-)
>
> on the 8-way box,
On Thu, 2005-08-25 at 21:34 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > > does the system truly lock up, or is this some transitional condition?
> > > In any case, i agree that this should be debugged independently of the
> > > pi_lock patch.
> >
> > Hmm, I
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > does the system truly lock up, or is this some transitional condition?
> > In any case, i agree that this should be debugged independently of the
> > pi_lock patch.
>
> Hmm, I forgot that you took out the bit_spin_lock fixes. I think this
>
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Here it is a little ambiguous. The process use to own the lock, but
> someone stole it. When grabbing a lock, I always grab the process
> lock first before grabbing the lock's lock, but this isn't necessary.
> So if you already have the two
On Thu, 2005-08-25 at 08:35 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Well, after turning off hrtimers, I keep getting one bug. A possible
> > soft lockup with the ext3 code. But this didn't seem to be caused by
> > the changes I made. So just to be sure, I
On Thu, 2005-08-25 at 10:47 -0400, Steven Rostedt wrote:
> OK, here it is. Against 2.6.13-rc7-rt1.
> @@ -1134,17 +1206,35 @@
> return 0;
>
> trace_lock_irqsave(_lock, flags, ti);
> + /*
> + * We are no longer blocked on the lock, so we are considered a
> + *
OK, here it is. Against 2.6.13-rc7-rt1.
Please, test it well. Make sure to turn off any debugging, especially
CONFIG_RT_DEADLOCK_DETECT. Since that would use a global trace_lock
that defeats the purpose of removing the pi_lock.
The patch to remove the single pi_lock:
-- Steve
Signed-off-by:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Well, after turning off hrtimers, I keep getting one bug. A possible
> soft lockup with the ext3 code. But this didn't seem to be caused by
> the changes I made. So just to be sure, I ran my test on the vanilla
> 2.6.13-rc6-rt11 and it gave the
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So, Ingo, what do you think of the changes so far? Do you feel that
> it is stable enough to send you an actual real patch. That way we can
> work together in cleaning it up and get all the other kinks out.
yeah, please send me a patch against
* Steven Rostedt [EMAIL PROTECTED] wrote:
So, Ingo, what do you think of the changes so far? Do you feel that
it is stable enough to send you an actual real patch. That way we can
work together in cleaning it up and get all the other kinks out.
yeah, please send me a patch against
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by
the changes I made. So just to be sure, I ran my test on the vanilla
2.6.13-rc6-rt11 and it gave the same bug
OK, here it is. Against 2.6.13-rc7-rt1.
Please, test it well. Make sure to turn off any debugging, especially
CONFIG_RT_DEADLOCK_DETECT. Since that would use a global trace_lock
that defeats the purpose of removing the pi_lock.
The patch to remove the single pi_lock:
-- Steve
Signed-off-by:
On Thu, 2005-08-25 at 10:47 -0400, Steven Rostedt wrote:
OK, here it is. Against 2.6.13-rc7-rt1.
@@ -1134,17 +1206,35 @@
return 0;
trace_lock_irqsave(trace_lock, flags, ti);
+ /*
+ * We are no longer blocked on the lock, so we are considered a
+ *
On Thu, 2005-08-25 at 08:35 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by
the changes I made. So just to be sure, I ran my test
* Steven Rostedt [EMAIL PROTECTED] wrote:
Here it is a little ambiguous. The process use to own the lock, but
someone stole it. When grabbing a lock, I always grab the process
lock first before grabbing the lock's lock, but this isn't necessary.
So if you already have the two locks
* Steven Rostedt [EMAIL PROTECTED] wrote:
does the system truly lock up, or is this some transitional condition?
In any case, i agree that this should be debugged independently of the
pi_lock patch.
Hmm, I forgot that you took out the bit_spin_lock fixes. I think this
may be
On Thu, 2005-08-25 at 21:34 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
does the system truly lock up, or is this some transitional condition?
In any case, i agree that this should be debugged independently of the
pi_lock patch.
Hmm, I forgot that you
On Thu, 2005-08-25 at 19:47 +0200, Ingo Molnar wrote:
your patch works great here, on 3 separate systems: a 1-way, a 2/4-way
and an 8-way.
the 1-way system performed so well running the SMP kernel that i first
thought i booted the UP kernel by accident :-)
on the 8-way box, hackbench
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
A word of caution (aka. disclaimer). This is still new. I still expect
there are some cases in the code that was missed and can cause a dead
lock or other bad side effect. Hopefully, we can iron these all out.
Also, I noticed that
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
A word of caution (aka. disclaimer). This is still new. I still expect
there are some cases in the code that was missed and can cause a dead
lock or other bad side effect. Hopefully, we can iron these all out.
Also, I noticed that
On Wed, 24 Aug 2005, Daniel Walker wrote:
>
> I got a report of a possible softlockup with setiathome, the trace
> wasn't a little garbled though . I'm not sure the checking is working
> correctly . But if it is maybe these spot need some performance
> analysis . Didn't you changes catch
On Wed, 2005-08-24 at 21:13 -0400, Steven Rostedt wrote:
> Well, after turning off hrtimers, I keep getting one bug. A possible
> soft lockup with the ext3 code. But this didn't seem to be caused by the
> changes I made. So just to be sure, I ran my test on the vanilla
> 2.6.13-rc6-rt11 and it
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by the
changes I made. So just to be sure, I ran my test on the vanilla
2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my
changes are now at par
On Wed, 2005-08-24 at 16:56 -0400, Steven Rostedt wrote:
> Also Thomas,
>
> I'm still triggering that "huh?" statement in pi_setprio, and it is
> always with the softirq-hrtimer thread. It likes to change its
> priorities, but there's a time when p->normal_prio != normal_prio(p).
> And this is
On Wed, 2005-08-24 at 16:56 -0400, Steven Rostedt wrote:
Also Thomas,
I'm still triggering that huh? statement in pi_setprio, and it is
always with the softirq-hrtimer thread. It likes to change its
priorities, but there's a time when p-normal_prio != normal_prio(p).
And this is what's
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by the
changes I made. So just to be sure, I ran my test on the vanilla
2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my
changes are now at par
On Wed, 2005-08-24 at 21:13 -0400, Steven Rostedt wrote:
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by the
changes I made. So just to be sure, I ran my test on the vanilla
2.6.13-rc6-rt11 and it gave
On Wed, 24 Aug 2005, Daniel Walker wrote:
I got a report of a possible softlockup with setiathome, the trace
wasn't a little garbled though . I'm not sure the checking is working
correctly . But if it is maybe these spot need some performance
analysis . Didn't you changes catch anything
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > One downside would be an increase in mutex structure size though.
>
> If I do need to add an additional lock to the mutex, I would abstract
> it all, so that the old global pi_lock can be used if configured.
> This way, a UP or a low memory 2x
On Mon, 2005-08-22 at 21:32 -0400, Steven Rostedt wrote:
>
> God, I think a thesis can be made out of this. Well, let me start
> coding, since I'm one of those that write code better than I design.
> I'm a Spiral type of guy, not a Waterfall one ;-)
> Code crap, write about it, recode it as
On Mon, 2005-08-22 at 17:51 -0700, Daniel Walker wrote:
> On Mon, 2005-08-22 at 20:26 -0400, Steven Rostedt wrote:
>
> >
> > How would you add to a lock with just holding a lock for a task? When
> > you are grabbing a lock, you must first grab a raw lock associated to
> > the lock being
On Mon, 2005-08-22 at 20:26 -0400, Steven Rostedt wrote:
>
> How would you add to a lock with just holding a lock for a task? When
> you are grabbing a lock, you must first grab a raw lock associated to
> the lock being grabbed. Although, I'm starting to look into this idea,
> and I'm going to
On Mon, 2005-08-22 at 15:19 -0700, Daniel Walker wrote:
> On Mon, 2005-08-22 at 15:44 -0400, Steven Rostedt wrote:
> > On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
> >
> > > any ideas how to get rid of pi_lock altogether?
> >
> > I've toyed with the idea of adding another raw_spin_lock
On Mon, 2005-08-22 at 15:44 -0400, Steven Rostedt wrote:
> On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
>
> > any ideas how to get rid of pi_lock altogether?
>
> I've toyed with the idea of adding another raw_spin_lock to the mutex. A
> lock specific pi_lock. Instead of grabbing a
On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
> any ideas how to get rid of pi_lock altogether?
I've toyed with the idea of adding another raw_spin_lock to the mutex. A
lock specific pi_lock. Instead of grabbing a global pi_lock, grab the
pi_lock of a lock. To modify any lock w.r.t
On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
any ideas how to get rid of pi_lock altogether?
I've toyed with the idea of adding another raw_spin_lock to the mutex. A
lock specific pi_lock. Instead of grabbing a global pi_lock, grab the
pi_lock of a lock. To modify any lock w.r.t PI,
On Mon, 2005-08-22 at 15:44 -0400, Steven Rostedt wrote:
On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
any ideas how to get rid of pi_lock altogether?
I've toyed with the idea of adding another raw_spin_lock to the mutex. A
lock specific pi_lock. Instead of grabbing a global
On Mon, 2005-08-22 at 15:19 -0700, Daniel Walker wrote:
On Mon, 2005-08-22 at 15:44 -0400, Steven Rostedt wrote:
On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
any ideas how to get rid of pi_lock altogether?
I've toyed with the idea of adding another raw_spin_lock to the
On Mon, 2005-08-22 at 20:26 -0400, Steven Rostedt wrote:
How would you add to a lock with just holding a lock for a task? When
you are grabbing a lock, you must first grab a raw lock associated to
the lock being grabbed. Although, I'm starting to look into this idea,
and I'm going to
On Mon, 2005-08-22 at 17:51 -0700, Daniel Walker wrote:
On Mon, 2005-08-22 at 20:26 -0400, Steven Rostedt wrote:
How would you add to a lock with just holding a lock for a task? When
you are grabbing a lock, you must first grab a raw lock associated to
the lock being grabbed.
On Mon, 2005-08-22 at 21:32 -0400, Steven Rostedt wrote:
God, I think a thesis can be made out of this. Well, let me start
coding, since I'm one of those that write code better than I design.
I'm a Spiral type of guy, not a Waterfall one ;-)
Code crap, write about it, recode it as gold!
* Steven Rostedt [EMAIL PROTECTED] wrote:
One downside would be an increase in mutex structure size though.
If I do need to add an additional lock to the mutex, I would abstract
it all, so that the old global pi_lock can be used if configured.
This way, a UP or a low memory 2x SMP
52 matches
Mail list logo
