linux-kernel - Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler

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, 22 Feb 2016 12:48:54 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Daniel Bristot de Oliveira <bristot@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Juri Lelli <juri.lelli@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler

On Mon, 22 Feb 2016 18:32:59 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> So I'm a bit allergic to tracepoints and this is very flimsy on reasons
> why I would want to do this.

Because there's no way to know if SCHED_DEADLINE tasks are doing what
they suppose to without hacking the kernel and adding your own
tracepoints.

> 
> As it stands, the existing tracepoint have already been an ABI
> trainwreck, why would I want to add more?

Yes, this may become a type of ABI, but even the sched switch
tracepoints haven't been that bad. Has it really prevented us from
changing anything?

"trainwreck" is a harsh word, and the information of scheduling
tracepoints have been crucial to finding bugs and such. And has been
tremendously useful in loads of cases.

But let me ask, what would you recommend to finding out if the kernel
has really given your tasks the recommended runtime within a given
period? We can't expect users of SCHED_DEADLINE to be modifying the
kernel themselves.

-- Steve