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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Dec 2014 09:55:58 -0500
From:	Josef Bacik <jbacik@...com>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
CC:	<bmaurer@...com>, <rkroll@...com>, <kernel-team@...com>,
	<mingo@...hat.com>, <peterz@...radead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [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
--
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/