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

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:	Mon, 15 Dec 2014 11:16:25 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Josef Bacik <jbacik@...com>
Cc:	bmaurer@...com, rkroll@...com, kernel-team@...com,
	mingo@...hat.com, linux-kernel@...r.kernel.org,
	umgwanakikbuti@...il.com
Subject: Re: [PATCH] sched/fair: change where we report sched stats V2

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 useless when
> trying to track down latency spikes, as we want to know why we were put to sleep
> for as long as we were.
> 
> This patch moves the trace_sched_stat* calls to after the task has been put back
> on the CPU so that the backtrace we get is the one that put us to sleep.  Mike
> Galbraith suggested that I leave the actual stat collection stuff where it is so
> that we don't add the scheduler latency to the sleep stats, so I've added 3 new
> fields in the scheduler stats to keep track of the last sleep time so that if
> any of these are set we know to trigger the trace points.  Thanks,
> 

Yeah, so I don't like this, it adds overhead for everyone.

Also, I'm very sure this issue has been raised before, and I'm pretty
sure the answer back then was why don't you look at the
trace_sched_switch() site matching this wakeup?
--
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/