On Sun, Jul 13, 2014 at 05:43:13PM -0400, Sasha Levin wrote:
> On 07/11/2014 11:59 AM, Peter Zijlstra wrote:
> >>> I agree with you that "The call trace is very clear on it that its not",
> >>> but
> >>> > > when you have 500 call traces you really want something better than
> >>> > > going
> >>>
On 07/11/2014 11:59 AM, Peter Zijlstra wrote:
>>> I agree with you that "The call trace is very clear on it that its not", but
>>> > > when you have 500 call traces you really want something better than
>>> > > going
>>> > > through it one call trace at a time.
>> >
>> > Points well made, and I s
On Fri, Jul 11, 2014 at 07:55:50AM -0700, Hugh Dickins wrote:
> On Fri, 11 Jul 2014, Sasha Levin wrote:
> >
> > There's no easy way to see whether a given task is actually holding a lock
> > or
> > is just blocking on it without going through all those tasks one by one and
> > looking at their tr
On Fri, 11 Jul 2014, Sasha Levin wrote:
>
> There's no easy way to see whether a given task is actually holding a lock or
> is just blocking on it without going through all those tasks one by one and
> looking at their trace.
>
> I agree with you that "The call trace is very clear on it that its
On 07/11/2014 04:25 AM, Peter Zijlstra wrote:
> On Thu, Jul 10, 2014 at 03:02:29PM -0400, Sasha Levin wrote:
>> What if we move lockdep's acquisition point to after it actually got the
>> lock?
>
> NAK, you want to do deadlock detection _before_ you're stuck in a
> deadlock.
I didn't suggest to d
On 07/11/2014 10:38 AM, Peter Zijlstra wrote:
On Fri, Jul 11, 2014 at 10:33:15AM +0200, Vlastimil Babka wrote:
Quoting Hugh from previous mail in this thread:
[ 363.600969] INFO: task trinity-c327:9203 blocked for more than 120 seconds.
[ 363.605359] Not tainted
3.16.0-rc4-next-20140
On Fri, Jul 11, 2014 at 10:33:15AM +0200, Vlastimil Babka wrote:
> Quoting Hugh from previous mail in this thread:
>
> >>>
> >>> [ 363.600969] INFO: task trinity-c327:9203 blocked for more than 120
> >>> seconds.
> >>> [ 363.605359] Not tainted
> >>> 3.16.0-rc4-next-20140708-sasha-00022-
On 07/11/2014 10:25 AM, Peter Zijlstra wrote:
On Thu, Jul 10, 2014 at 03:02:29PM -0400, Sasha Levin wrote:
What if we move lockdep's acquisition point to after it actually got the
lock?
NAK, you want to do deadlock detection _before_ you're stuck in a
deadlock.
We'd miss deadlocks, but we do
On Thu, Jul 10, 2014 at 03:02:29PM -0400, Sasha Levin wrote:
> What if we move lockdep's acquisition point to after it actually got the
> lock?
NAK, you want to do deadlock detection _before_ you're stuck in a
deadlock.
> We'd miss deadlocks, but we don't care about them right now. Anyways, doesn
On Thu, 10 Jul 2014, Hugh Dickins wrote:
> On Thu, 10 Jul 2014, Sasha Levin wrote:
> > On 07/10/2014 01:55 PM, Hugh Dickins wrote:
> > >> And finally, (not) holding the i_mmap_mutex:
> > > I don't understand what prompts you to show this particular task.
> > > I imagine the dump shows lots of other
On Thu, 10 Jul 2014, Hugh Dickins wrote:
>
> I'll pore over the new log. It does help to know that its base kernel
> is more stable: thanks so much. But whether I can work out any more...
Actually, today's log is not much use to me: for a tenth of a second
it just shows "NNN printk messages dro
On Thu, 10 Jul 2014, Sasha Levin wrote:
> On 07/10/2014 03:06 PM, Hugh Dickins wrote:
> > On Thu, 10 Jul 2014, Sasha Levin wrote:
> >> > On 07/10/2014 02:52 PM, Hugh Dickins wrote:
> >>> > > On Thu, 10 Jul 2014, Sasha Levin wrote:
> > > >> > On 07/10/2014 01:55 PM, Hugh Dickins wrote:
> >>>
On 07/10/2014 03:06 PM, Hugh Dickins wrote:
> On Thu, 10 Jul 2014, Sasha Levin wrote:
>> > On 07/10/2014 02:52 PM, Hugh Dickins wrote:
>>> > > On Thu, 10 Jul 2014, Sasha Levin wrote:
> > >> > On 07/10/2014 01:55 PM, Hugh Dickins wrote:
> > > >> And finally, (not) holding the i_mmap
On Thu, 10 Jul 2014, Sasha Levin wrote:
> On 07/10/2014 02:52 PM, Hugh Dickins wrote:
> > On Thu, 10 Jul 2014, Sasha Levin wrote:
> >> > On 07/10/2014 01:55 PM, Hugh Dickins wrote:
> > >> And finally, (not) holding the i_mmap_mutex:
> >>> > > I don't understand what prompts you to show this pa
On 07/10/2014 02:52 PM, Hugh Dickins wrote:
> On Thu, 10 Jul 2014, Sasha Levin wrote:
>> > On 07/10/2014 01:55 PM, Hugh Dickins wrote:
> >> And finally, (not) holding the i_mmap_mutex:
>>> > > I don't understand what prompts you to show this particular task.
>>> > > I imagine the dump shows lo
On Thu, 10 Jul 2014, Sasha Levin wrote:
> On 07/10/2014 01:55 PM, Hugh Dickins wrote:
> >> And finally, (not) holding the i_mmap_mutex:
> > I don't understand what prompts you to show this particular task.
> > I imagine the dump shows lots of other tasks which are waiting to get an
> > i_mmap_mutex
On Thu, 10 Jul 2014, Sasha Levin wrote:
> On 07/10/2014 08:46 AM, Sasha Levin wrote:
> > On 07/10/2014 03:37 AM, Hugh Dickins wrote:
> >> > I do think that the most useful thing you could do at the moment,
> >> > is to switch away from running trinity on -next temporarily, and
> >> > run it instead
On 07/10/2014 08:46 AM, Sasha Levin wrote:
> On 07/10/2014 03:37 AM, Hugh Dickins wrote:
>> > I do think that the most useful thing you could do at the moment,
>> > is to switch away from running trinity on -next temporarily, and
>> > run it instead on Linus's current git or on 3.16-rc4, but with
>
On 07/10/2014 03:37 AM, Hugh Dickins wrote:
> I do think that the most useful thing you could do at the moment,
> is to switch away from running trinity on -next temporarily, and
> run it instead on Linus's current git or on 3.16-rc4, but with
> f00cdc6df7d7 reverted and my "take 2" inserted in its
On Wed, 9 Jul 2014, Sasha Levin wrote:
> On 07/09/2014 08:47 AM, Sasha Levin wrote:
> >> > So it would again help to see stacks of other tasks, to see who holds
> >> > the i_mutex and where it's stuck...
> > The stacks print got garbled due to having large amount of tasks and too
> > low of a
> >
On Wed, 9 Jul 2014, Hugh Dickins wrote:
> On Wed, 9 Jul 2014, Vlastimil Babka wrote:
> > On 07/09/2014 06:03 PM, Sasha Levin wrote:
> > >
> > > We can see that it's not blocked since it's in the middle of a spinlock
> > > unlock
> > > call, and we can guess it's been in that function for a while b
On Wed, 9 Jul 2014, Vlastimil Babka wrote:
> On 07/09/2014 06:03 PM, Sasha Levin wrote:
> >
> > We can see that it's not blocked since it's in the middle of a spinlock
> > unlock
> > call, and we can guess it's been in that function for a while because of
> > the hung
> > task timer, and other pro
On 07/09/2014 06:03 PM, Sasha Levin wrote:
On 07/09/2014 08:47 AM, Sasha Levin wrote:
So it would again help to see stacks of other tasks, to see who holds the
i_mutex and where it's stuck...
The stacks print got garbled due to having large amount of tasks and too low of
a
console buffer. I'v
On 07/09/2014 05:50 AM, Vlastimil Babka wrote:
> On 07/09/2014 08:35 AM, Hugh Dickins wrote:
>> On Wed, 9 Jul 2014, Sasha Levin wrote:
>>> [ 363.600969] INFO: task trinity-c327:9203 blocked for more than 120
>>> seconds.
>>> [ 363.605359] Not tainted
>>> 3.16.0-rc4-next-20140708-sasha-000
On 07/09/2014 08:35 AM, Hugh Dickins wrote:
On Wed, 9 Jul 2014, Sasha Levin wrote:
On 07/02/2014 03:25 PM, a...@linux-foundation.org wrote:
From: Hugh Dickins
Subject: shmem: fix faulting into a hole while it's punched, take 2
I suspect there's something off with this patch, as the shmem_fal
On Wed, 9 Jul 2014, Sasha Levin wrote:
> On 07/02/2014 03:25 PM, a...@linux-foundation.org wrote:
> > From: Hugh Dickins
> > Subject: shmem: fix faulting into a hole while it's punched, take 2
>
> I suspect there's something off with this patch, as the shmem_fallocate
> hangs are back... Pretty m
On 07/02/2014 03:25 PM, a...@linux-foundation.org wrote:
>
> The patch titled
> Subject: shmem: fix faulting into a hole while it's punched, take 2
> has been added to the -mm tree. Its filename is
> shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch
>
> This patch should so
27 matches
Mail list logo
