lkml.org 
[lkml]   [2014]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched/fair: change where we report sched stats
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


\
 
 \ /
  Last update: 2014-12-11 16:41    [W:0.048 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site