On Tue, 10 Jun 2014, Steven Rostedt wrote:
> On Tue, 10 Jun 2014 19:43:16 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Tue, 10 Jun 2014, Steven Rostedt wrote:
> >
> > > On Tue, 10 Jun 2014 09:57:25 -0500
> > > "Brad Mouring" wrote:
> > >
> > >
> > > > > + /* Store whether owner
On Tue, 10 Jun 2014, Steven Rostedt wrote:
> On Tue, 10 Jun 2014 19:41:39 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > > On the loop back around, have something like:
> > >
> > > if (top_waiter) {
> > > if (!task_has_pi_waiters(task))
> > > goto out_unlock_pi;
>
On Tue, 10 Jun 2014 19:43:16 +0200 (CEST)
Thomas Gleixner wrote:
> On Tue, 10 Jun 2014, Steven Rostedt wrote:
>
> > On Tue, 10 Jun 2014 09:57:25 -0500
> > "Brad Mouring" wrote:
> >
> >
> > > > + /* Store whether owner is blocked itself and drop locks
> > > > */
> > > > +
On Tue, 10 Jun 2014 19:41:39 +0200 (CEST)
Thomas Gleixner wrote:
> > On the loop back around, have something like:
> >
> > if (top_waiter) {
> > if (!task_has_pi_waiters(task))
> > goto out_unlock_pi;
>
> The task has at least one pi waiter.
>
> >
On Tue, 10 Jun 2014, Steven Rostedt wrote:
> On Tue, 10 Jun 2014 09:57:25 -0500
> "Brad Mouring" wrote:
>
>
> > > + /* Store whether owner is blocked itself and drop locks */
> > > + next_lock = task_blocked_on(task);
> > task_blocked_on(task) is not clear to me, the recipient o
On Mon, 9 Jun 2014, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:10 -
> Thomas Gleixner wrote:
> > /*
> > +* If we just follow the lock chain for deadlock detection, no
> > +* need to do all the requeue operations. We avoid a truckload
>
> s/We/To/
>
>
> > +* of conditi
On Tue, 10 Jun 2014 09:57:25 -0500
"Brad Mouring" wrote:
> > + /* Store whether owner is blocked itself and drop locks */
> > + next_lock = task_blocked_on(task);
> task_blocked_on(task) is not clear to me, the recipient of the
> return is the only clue that hints at what the
On Mon, Jun 09, 2014 at 08:28:10PM -, Thomas Gleixner wrote:
> In case the dead lock detector is enabled we follow the lock chain to
> the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
> due to the priority/waiter constellation.
>
> But once we are not longer the top priorit
On Mon, Jun 9, 2014 at 6:20 PM, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:10 -
> Thomas Gleixner wrote:
>
>> In case the dead lock detector is enabled we follow the lock chain to
>> the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
>> due to the priority/waiter cons
On Mon, 09 Jun 2014 20:28:10 -
Thomas Gleixner wrote:
> In case the dead lock detector is enabled we follow the lock chain to
> the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
> due to the priority/waiter constellation.
>
> But once we are not longer the top priority wai
In case the dead lock detector is enabled we follow the lock chain to
the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
due to the priority/waiter constellation.
But once we are not longer the top priority waiter in a certain step
or the task holding the lock has already the sam
11 matches
Mail list logo
