Re: [PATCH] sched/fair: change where we report sched stats

[Josef Bacik <jbacik@fb.com>]

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/block ends when the task is awakened/enqueued, not when it
>>> gets the CPU.  You're adding scheduling latency, breaking accounting.
>>>
>>
>> Yes I'm aware of that.  I don't care if the delay time is slightly
>> higher than normal, I care about knowing exactly why we were sleeping to
>> begin with.  I suppose I could leave the accounting part where it is and
>> then just fire the tracepoint when it's put on the CPU so we get the
>> best of both worlds, but honestly I don't feel like adding the extra
>> scheduling latency into the accounting is that big of a deal.  Thanks,
>
> I think sleep/iowait should remain what they are, sleep/iowait end at
> wakeup.  I don't think waker trace is useless either for that matter.
> Who/when ends a sleep period is just as much a part of the picture as
> what triggered that sleep.  Waker scheduling latency, thumb twiddling
> etc. extend sleep.
>

Ok I'll re-roll with the stats themselves not changed.  We can get the 
waker other ways, but if we're wanting to see how long we were asleep we 
are probably going to want to know why.

> Shrug, maintainer call.  I don't recall ever having any difficulty
> determining why a task went to sleep, so don't get it.
>

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 to hear it.  Thanks,

Josef