[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110426194428.GA8029@linux.vnet.ibm.com>
Date: Tue, 26 Apr 2011 12:44:28 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: sedat.dilek@...il.com, Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for April 14 (Call-traces: RCU/ACPI/WQ
related?)
On Tue, Apr 26, 2011 at 04:31:13AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 26, 2011 at 12:06:57PM +0200, Peter Zijlstra wrote:
> > On Sun, 2011-04-24 at 09:43 -0700, Paul E. McKenney wrote:
> > >
> > > Peter, any thoughts on what I might have done wrong to get the scheduler
> > > into a state where it was ignoring a runnable realtime task?
> >
> > Not really, the only thing I can think of is something like poking at
> > task->state while its sleeping. One you set it to TASK_RUNNING wakeups
> > will be ignored since its already running ;-)
>
> Well, that does give my something to check for -- thank you!
OK. So I don't poke TASK_RUNNING into task->state, but I do poke
TASK_INTERRUPTIBLE into it via schedule_timeout_interruptible().
This happens without synchronization, and could run concurrently with
a wake_up() -- though from what I can see, if the task was running,
the wait queue would be empty, so nothing would happen.
However, Bruno's stack dump leads me to believe that the badness happened
while rcu_kthread was in schedule_timeout_interruptible().
So, is there something special I need to do for this case, where I
might have schedule_timeout_interruptible() concurrent with wake_up()
attempts?
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists