On Sat, Jul 5, 2014 at 1:26 PM, Thomas Gleixner wrote:
> On Mon, 30 Jun 2014, Austin Schuh wrote:
>> I think I might have an answer for my own question, but I would
>> appreciate someone else to double check. If list_empty erroneously
>> returns that there is work to do when there isn't work to
On Wed, 21 May 2014, John Blackwood wrote:
> I'm not 100% sure that the patch below will fix your problem, but we
> saw something that sounds pretty familiar to your issue involving the
> nvidia driver and the preempt-rt patch. The nvidia driver uses the
> completion support to create their own
On Mon, 30 Jun 2014, Austin Schuh wrote:
> I think I might have an answer for my own question, but I would
> appreciate someone else to double check. If list_empty erroneously
> returns that there is work to do when there isn't work to do, we wake
> up an extra worker which then goes back to
On Mon, 30 Jun 2014, Austin Schuh wrote:
I think I might have an answer for my own question, but I would
appreciate someone else to double check. If list_empty erroneously
returns that there is work to do when there isn't work to do, we wake
up an extra worker which then goes back to sleep.
On Wed, 21 May 2014, John Blackwood wrote:
I'm not 100% sure that the patch below will fix your problem, but we
saw something that sounds pretty familiar to your issue involving the
nvidia driver and the preempt-rt patch. The nvidia driver uses the
completion support to create their own
On Sat, Jul 5, 2014 at 1:26 PM, Thomas Gleixner t...@linutronix.de wrote:
On Mon, 30 Jun 2014, Austin Schuh wrote:
I think I might have an answer for my own question, but I would
appreciate someone else to double check. If list_empty erroneously
returns that there is work to do when there
On Thu, 2014-07-03 at 16:08 -0700, Austin Schuh wrote:
> On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh wrote:
> > On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh
> > wrote:
> >> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner
> >> wrote:
> >>> Completely untested patch below.
>
> I've tested
On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh wrote:
> On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh wrote:
>> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
>>> Completely untested patch below.
I've tested it and looked it over now, and feel pretty confident in
the patch. Thanks
On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh aus...@peloton-tech.com wrote:
On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh aus...@peloton-tech.com wrote:
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner t...@linutronix.de wrote:
Completely untested patch below.
I've tested it and looked it
On Thu, 2014-07-03 at 16:08 -0700, Austin Schuh wrote:
On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh aus...@peloton-tech.com wrote:
On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh aus...@peloton-tech.com
wrote:
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner t...@linutronix.de
wrote:
On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh wrote:
> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
>> Completely untested patch below.
>
> By chance, I found this in my boot logs. I'll do some more startup
> testing tomorrow.
>
> Jun 30 19:54:40 vpc5 kernel: [0.670955]
On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh aus...@peloton-tech.com wrote:
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner t...@linutronix.de wrote:
Completely untested patch below.
By chance, I found this in my boot logs. I'll do some more startup
testing tomorrow.
Jun 30 19:54:40 vpc5
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
> Completely untested patch below.
By chance, I found this in my boot logs. I'll do some more startup
testing tomorrow.
Jun 30 19:54:40 vpc5 kernel: [0.670955] [ cut here ]
Jun 30 19:54:40 vpc5 kernel: [
On Mon, Jun 30, 2014 at 5:12 PM, Austin Schuh wrote:
> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
>> On Thu, 26 Jun 2014, Austin Schuh wrote:
>>> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
>>> out of __schedule to sched_submit_work. It looks like that
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
> On Thu, 26 Jun 2014, Austin Schuh wrote:
>> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
>> out of __schedule to sched_submit_work. It looks like that changes
>> the conditions under which wq_worker_sleeping is
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner t...@linutronix.de wrote:
On Thu, 26 Jun 2014, Austin Schuh wrote:
If I'm reading the rt patch correctly, wq_worker_sleeping was moved
out of __schedule to sched_submit_work. It looks like that changes
the conditions under which
On Mon, Jun 30, 2014 at 5:12 PM, Austin Schuh aus...@peloton-tech.com wrote:
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner t...@linutronix.de wrote:
On Thu, 26 Jun 2014, Austin Schuh wrote:
If I'm reading the rt patch correctly, wq_worker_sleeping was moved
out of __schedule to
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner t...@linutronix.de wrote:
Completely untested patch below.
By chance, I found this in my boot logs. I'll do some more startup
testing tomorrow.
Jun 30 19:54:40 vpc5 kernel: [0.670955] [ cut here ]
Jun 30 19:54:40 vpc5
On Fri, 2014-06-27 at 23:20 -0700, Austin Schuh wrote:
> For workqueues, as long as the helper doesn't block on a lock which
> requires the work queue to be freed up, it will eventually become
> unblocked and make progress. The helper _should_ only need the pool
> lock, which will wake the
On Fri, Jun 27, 2014 at 8:32 PM, Mike Galbraith
wrote:
> On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote:
>
>> It would be more context switches, but I wonder if we could kick the
>> workqueue logic completely out of the scheduler into a thread. Have
>> the scheduler increment/decrement an
On Fri, Jun 27, 2014 at 8:32 PM, Mike Galbraith
umgwanakikb...@gmail.com wrote:
On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote:
It would be more context switches, but I wonder if we could kick the
workqueue logic completely out of the scheduler into a thread. Have
the scheduler
On Fri, 2014-06-27 at 23:20 -0700, Austin Schuh wrote:
For workqueues, as long as the helper doesn't block on a lock which
requires the work queue to be freed up, it will eventually become
unblocked and make progress. The helper _should_ only need the pool
lock, which will wake the helper
On Fri, 2014-06-27 at 16:24 +0200, Thomas Gleixner wrote:
> Completely untested patch below.
It's no longer completely untested, killer_module is no longer a killer.
I'll let box (lockdep etc is enabled) chew on it a while, no news is
good news as usual.
-Mike
--
To unsubscribe from this list:
On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote:
> It would be more context switches, but I wonder if we could kick the
> workqueue logic completely out of the scheduler into a thread. Have
> the scheduler increment/decrement an atomic pool counter, and wake up
> the monitoring thread to
On Fri, Jun 27, 2014 at 11:19 AM, Steven Rostedt wrote:
> On Fri, 27 Jun 2014 20:07:54 +0200
> Mike Galbraith wrote:
>
>> > Why do we need the wakeup? the owner of the lock should wake it up
>> > shouldn't it?
>>
>> True, but that can take ages.
>
> Can it? If the workqueue is of some higher
On Fri, 2014-06-27 at 14:19 -0400, Steven Rostedt wrote:
> On Fri, 27 Jun 2014 20:07:54 +0200
> Mike Galbraith wrote:
>
> > > Why do we need the wakeup? the owner of the lock should wake it up
> > > shouldn't it?
> >
> > True, but that can take ages.
>
> Can it? If the workqueue is of some
On Fri, 27 Jun 2014 20:07:54 +0200
Mike Galbraith wrote:
> > Why do we need the wakeup? the owner of the lock should wake it up
> > shouldn't it?
>
> True, but that can take ages.
Can it? If the workqueue is of some higher priority, it should boost
the process that owns the lock. Otherwise it
On Fri, 2014-06-27 at 13:54 -0400, Steven Rostedt wrote:
> On Fri, 27 Jun 2014 19:34:53 +0200
> Mike Galbraith wrote:
>
> > On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
> >
> > > This seems like a lot of hacks.
> >
> > It is exactly that, lacking proper pooper-scooper, show rt
On Fri, 27 Jun 2014 19:34:53 +0200
Mike Galbraith wrote:
> On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
>
> > This seems like a lot of hacks.
>
> It is exactly that, lacking proper pooper-scooper, show rt kernel how to
> not step in it.
>
> > I'm wondering if it would work if we
>
On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
> This seems like a lot of hacks.
It is exactly that, lacking proper pooper-scooper, show rt kernel how to
not step in it.
> I'm wondering if it would work if we
> just have the rt_spin_lock_slowlock not call schedule(), but call
>
On Thu, 26 Jun 2014, Austin Schuh wrote:
> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
> out of __schedule to sched_submit_work. It looks like that changes
> the conditions under which wq_worker_sleeping is called. It used to
> be called whenever a task was going to sleep
On Fri, 27 Jun 2014 14:57:36 +0200
Mike Galbraith wrote:
> On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:
>
> > I'm not sure where to go from there. Any changes to the workpool to
> > try to fix that will be hard, or could affect latency significantly.
>
> Oh what the hell, I'm out of
On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:
> I'm not sure where to go from there. Any changes to the workpool to
> try to fix that will be hard, or could affect latency significantly.
Oh what the hell, I'm out of frozen shark, may as well stock up. Nobody
else has posted spit yet.
On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:
I'm not sure where to go from there. Any changes to the workpool to
try to fix that will be hard, or could affect latency significantly.
Oh what the hell, I'm out of frozen shark, may as well stock up. Nobody
else has posted spit yet. I
On Fri, 27 Jun 2014 14:57:36 +0200
Mike Galbraith umgwanakikb...@gmail.com wrote:
On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:
I'm not sure where to go from there. Any changes to the workpool to
try to fix that will be hard, or could affect latency significantly.
Oh what the
On Thu, 26 Jun 2014, Austin Schuh wrote:
If I'm reading the rt patch correctly, wq_worker_sleeping was moved
out of __schedule to sched_submit_work. It looks like that changes
the conditions under which wq_worker_sleeping is called. It used to
be called whenever a task was going to sleep (I
On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
This seems like a lot of hacks.
It is exactly that, lacking proper pooper-scooper, show rt kernel how to
not step in it.
I'm wondering if it would work if we
just have the rt_spin_lock_slowlock not call schedule(), but call
On Fri, 27 Jun 2014 19:34:53 +0200
Mike Galbraith umgwanakikb...@gmail.com wrote:
On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
This seems like a lot of hacks.
It is exactly that, lacking proper pooper-scooper, show rt kernel how to
not step in it.
I'm wondering if it
On Fri, 2014-06-27 at 13:54 -0400, Steven Rostedt wrote:
On Fri, 27 Jun 2014 19:34:53 +0200
Mike Galbraith umgwanakikb...@gmail.com wrote:
On Fri, 2014-06-27 at 10:01 -0400, Steven Rostedt wrote:
This seems like a lot of hacks.
It is exactly that, lacking proper pooper-scooper,
On Fri, 27 Jun 2014 20:07:54 +0200
Mike Galbraith umgwanakikb...@gmail.com wrote:
Why do we need the wakeup? the owner of the lock should wake it up
shouldn't it?
True, but that can take ages.
Can it? If the workqueue is of some higher priority, it should boost
the process that owns the
On Fri, 2014-06-27 at 14:19 -0400, Steven Rostedt wrote:
On Fri, 27 Jun 2014 20:07:54 +0200
Mike Galbraith umgwanakikb...@gmail.com wrote:
Why do we need the wakeup? the owner of the lock should wake it up
shouldn't it?
True, but that can take ages.
Can it? If the workqueue is
On Fri, Jun 27, 2014 at 11:19 AM, Steven Rostedt rost...@goodmis.org wrote:
On Fri, 27 Jun 2014 20:07:54 +0200
Mike Galbraith umgwanakikb...@gmail.com wrote:
Why do we need the wakeup? the owner of the lock should wake it up
shouldn't it?
True, but that can take ages.
Can it? If the
On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote:
It would be more context switches, but I wonder if we could kick the
workqueue logic completely out of the scheduler into a thread. Have
the scheduler increment/decrement an atomic pool counter, and wake up
the monitoring thread to spawn
On Fri, 2014-06-27 at 16:24 +0200, Thomas Gleixner wrote:
Completely untested patch below.
It's no longer completely untested, killer_module is no longer a killer.
I'll let box (lockdep etc is enabled) chew on it a while, no news is
good news as usual.
-Mike
--
To unsubscribe from this list:
On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:
> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
> out of __schedule to sched_submit_work. It looks like that changes
> the conditions under which wq_worker_sleeping is called. It used to
> be called whenever a task was
On Thu, Jun 26, 2014 at 3:35 PM, Thomas Gleixner wrote:
> On Thu, 26 Jun 2014, Austin Schuh wrote:
>> On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
>> wrote:
>> > CC'ing RT folks
>> >
>> > On Wed, May 21, 2014 at 8:23 AM, Austin Schuh
>> > wrote:
>> >> On Tue, May 13, 2014 at 7:29 PM,
On Thu, 26 Jun 2014, Austin Schuh wrote:
> On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
> wrote:
> > CC'ing RT folks
> >
> > On Wed, May 21, 2014 at 8:23 AM, Austin Schuh
> > wrote:
> >> On Tue, May 13, 2014 at 7:29 PM, Austin Schuh
> >> wrote:
> >>> Hi,
> >>>
> >>> I am observing a
On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
wrote:
> CC'ing RT folks
>
> On Wed, May 21, 2014 at 8:23 AM, Austin Schuh wrote:
>> On Tue, May 13, 2014 at 7:29 PM, Austin Schuh
>> wrote:
>>> Hi,
>>>
>>> I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
>>> patched
On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
richard.weinber...@gmail.com wrote:
CC'ing RT folks
On Wed, May 21, 2014 at 8:23 AM, Austin Schuh aus...@peloton-tech.com wrote:
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh aus...@peloton-tech.com
wrote:
Hi,
I am observing a
On Thu, 26 Jun 2014, Austin Schuh wrote:
On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
richard.weinber...@gmail.com wrote:
CC'ing RT folks
On Wed, May 21, 2014 at 8:23 AM, Austin Schuh aus...@peloton-tech.com
wrote:
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh
On Thu, Jun 26, 2014 at 3:35 PM, Thomas Gleixner t...@linutronix.de wrote:
On Thu, 26 Jun 2014, Austin Schuh wrote:
On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
richard.weinber...@gmail.com wrote:
CC'ing RT folks
On Wed, May 21, 2014 at 8:23 AM, Austin Schuh
On Thu, 2014-06-26 at 17:07 -0700, Austin Schuh wrote:
If I'm reading the rt patch correctly, wq_worker_sleeping was moved
out of __schedule to sched_submit_work. It looks like that changes
the conditions under which wq_worker_sleeping is called. It used to
be called whenever a task was
On Wed, May 21, 2014 at 12:30 PM, John Blackwood
wrote:
>> Date: Wed, 21 May 2014 03:33:49 -0400
>> From: Richard Weinberger
>> To: Austin Schuh
>> CC: LKML , xfs , rt-users
>>
>> Subject: Re: Filesystem lockup with CONFIG_PREEMPT_RT
>
>>
> Date: Wed, 21 May 2014 03:33:49 -0400
> From: Richard Weinberger
> To: Austin Schuh
> CC: LKML , xfs , rt-users
>
> Subject: Re: Filesystem lockup with CONFIG_PREEMPT_RT
>
> CC'ing RT folks
>
> On Wed, May 21, 2014 at 8:23 AM, Austin Schuh wrote:
> &g
CC'ing RT folks
On Wed, May 21, 2014 at 8:23 AM, Austin Schuh wrote:
> On Tue, May 13, 2014 at 7:29 PM, Austin Schuh wrote:
>> Hi,
>>
>> I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
>> patched kernel. I have currently only triggered it using dpkg. Dave
>> Chinner on the
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh wrote:
> Hi,
>
> I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
> patched kernel. I have currently only triggered it using dpkg. Dave
> Chinner on the XFS mailing list suggested that it was a rt-kernel
> workqueue issue as
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh aus...@peloton-tech.com wrote:
Hi,
I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
patched kernel. I have currently only triggered it using dpkg. Dave
Chinner on the XFS mailing list suggested that it was a rt-kernel
CC'ing RT folks
On Wed, May 21, 2014 at 8:23 AM, Austin Schuh aus...@peloton-tech.com wrote:
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh aus...@peloton-tech.com wrote:
Hi,
I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
patched kernel. I have currently only triggered it
Date: Wed, 21 May 2014 03:33:49 -0400
From: Richard Weinberger richard.weinber...@gmail.com
To: Austin Schuh aus...@peloton-tech.com
CC: LKML linux-kernel@vger.kernel.org, xfs x...@oss.sgi.com, rt-users
linux-rt-us...@vger.kernel.org
Subject: Re: Filesystem lockup with CONFIG_PREEMPT_RT
linux-rt-us...@vger.kernel.org
Subject: Re: Filesystem lockup with CONFIG_PREEMPT_RT
CC'ing RT folks
On Wed, May 21, 2014 at 8:23 AM, Austin Schuh aus...@peloton-tech.com
wrote:
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh
aus...@peloton-tech.com wrote:
Hi,
I am observing
Hi,
I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
patched kernel. I have currently only triggered it using dpkg. Dave
Chinner on the XFS mailing list suggested that it was a rt-kernel
workqueue issue as opposed to a XFS problem after looking at the
kernel messages.
$ uname
Hi,
I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
patched kernel. I have currently only triggered it using dpkg. Dave
Chinner on the XFS mailing list suggested that it was a rt-kernel
workqueue issue as opposed to a XFS problem after looking at the
kernel messages.
$ uname
62 matches
Mail list logo
