On Mon, Dec 15, 2014 at 06:21:29PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 15, 2014 at 10:37:09AM -0500, Josef Bacik wrote:
>
> > >Yeah, so I don't like this, it adds overhead for everyone.
> > >
> >
> > Only if SCHEDSTATS is enabled tho, and it's no more overhead in the
> > SCHEDSTATS case th
On Mon, Dec 15, 2014 at 10:37:09AM -0500, Josef Bacik wrote:
> >Yeah, so I don't like this, it adds overhead for everyone.
> >
>
> Only if SCHEDSTATS is enabled tho, and it's no more overhead in the
> SCHEDSTATS case than before. Would it be more acceptable to move the entire
> callback under SC
On 12/15/2014 05:16 AM, Peter Zijlstra wrote:
On Thu, Dec 11, 2014 at 10:59:55AM -0500, Josef Bacik wrote:
The schedule stats currently spit out once the entity is being queued, which
means if we have stack traces enabled we will get the stack trace of the waker,
not of the task being woken. Th
On Thu, Dec 11, 2014 at 10:59:55AM -0500, Josef Bacik wrote:
> The schedule stats currently spit out once the entity is being queued, which
> means if we have stack traces enabled we will get the stack trace of the
> waker,
> not of the task being woken. This makes the backtrace completely useles
On Thu, 2014-12-11 at 09:55 -0500, Josef Bacik wrote:
> How did you do it? I had one latency spike in a 90 minute test that
> runs across 30 boxes that could have been caused by anything, so if
> there is a way I could have easily found that without moving these
> tracepoints around I'd love t
The schedule stats currently spit out once the entity is being queued, which
means if we have stack traces enabled we will get the stack trace of the waker,
not of the task being woken. This makes the backtrace completely useless when
trying to track down latency spikes, as we want to know why we
On 12/10/2014 10:34 PM, Mike Galbraith wrote:
On Wed, 2014-12-10 at 16:48 -0500, Josef Bacik wrote:
On 12/10/2014 01:23 AM, Mike Galbraith wrote:
On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:
This patch moves stat stuff to after the schedule, right as we are waking up,
But sleep/blo
On Wed, 2014-12-10 at 16:48 -0500, Josef Bacik wrote:
> On 12/10/2014 01:23 AM, Mike Galbraith wrote:
> > On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:
> >
> >> This patch moves stat stuff to after the schedule, right as we are waking
> >> up,
> >
> > But sleep/block ends when the task is
On 12/10/2014 01:23 AM, Mike Galbraith wrote:
On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:
This patch moves stat stuff to after the schedule, right as we are waking up,
But sleep/block ends when the task is awakened/enqueued, not when it
gets the CPU. You're adding scheduling latenc
On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:
> This patch moves stat stuff to after the schedule, right as we are waking up,
But sleep/block ends when the task is awakened/enqueued, not when it
gets the CPU. You're adding scheduling latency, breaking accounting.
-Mike
--
To unsubscri
The schedule stats currently spit out once the entity is being queued, which
means if we have stack traces enabled we will get the stack trace of the waker,
not of the task being woken. This makes the backtrace completely useless when
trying to track down latency spikes, as we want to know why we
11 matches
Mail list logo
