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 proces
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
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
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, ol
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, "hack
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 fo
* 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
> ma
* 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 lock
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 ra
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
> +
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: S
* 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 sam
* 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 2.6
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
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
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 w
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 w
* 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 S
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
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 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 t
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 glob
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,
26 matches
Mail list logo
