[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFx1Eech-MXWgJkERjJPSeg_9HVyLo_8nz=saNJyNmS7Kg@mail.gmail.com>
Date: Tue, 10 Dec 2013 13:18:20 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Darren Hart <dvhart@...ux.intel.com>
Cc: Dave Jones <davej@...hat.com>, Oleg Nesterov <oleg@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrea Arcangeli <aarcange@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Mel Gorman <mgorman@...e.de>
Subject: Re: process 'stuck' at exit.
On Tue, Dec 10, 2013 at 1:06 PM, Darren Hart <dvhart@...ux.intel.com> wrote:
>
> . Knowing exactly what syscall was made would
> be very useful, but I don't know if that information is even available
> anymore.
Well, the loop should be visible in the profile, since it's still active.
So doing something like
perf record -e cycles:pp -g -a sleep 60
to get a good profile for a minute, and then looking at the
instruction-level profiles in futex_requeue() should be possible.
Of course, inlining etc often makes those rather hard to see, and the
bulk of the profile is clearly all about the lock debugging overhead,
but if the loop is in futex_requeue() then that *should* be visible in
the profile, even if it may not be anywhere near the top..
Dave?
Linus
--
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