linux-kernel - Re: [PATCH V2 3/3] 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:	Tue, 29 Mar 2016 14:10:35 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Daniel Bristot de Oliveira <bristot@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Juri Lelli <juri.lelli@....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 V2 3/3] sched/deadline: Tracepoints for deadline
 scheduler

On Tue, 29 Mar 2016 14:37:18 -0300
Daniel Bristot de Oliveira <bristot@...hat.com> wrote:


> The above tracepoints are conditional, if dl_se->dl_yielded, only the
> yield tracepoint will happen. If !dl_se->dl_yielded, only the throttle
> tracepoint will happen.

Yes, I know they are conditional, but that doesn't make up the fact
that there's two tracepoints back to back, which should not happen.

> 
> We can try to join the sched_deadline_(yield|throttle|block) on a single
> tracepoint, but IMHO having them separated is more intuitive for users.

A userspace tool can make it more intuitive for users.

Note, tracepoints are very low overhead when not enabled. But they are
not zero percent overhead. That means, two tracepoints just doubled
that small overhead. Each one adds to the I$.

> 
> > Sure, we'll probably want to figure out a better way to see deadline
> > tasks blocked. Probably can see that from sched switch though, as it
> > would be in the blocked state as it scheduled out.  
> 
> We can guess that in the sched switch, but it currently does not show
> deadline specific information (deadline, runtime, now (in the timer used
> by the scheduler), and they are relevant in the analysis of deadline tasks.

But as I said in another email, it can be extended dynamically.

> 
> > 
> > Hmm, I probably could add tracing infrastructure that would let us
> > extend existing tracepoints. That is, without modifying sched_switch,
> > we could add a new tracepoint that when enabled, would attach itself to
> > the sched_switch tracepoint and record different information. Like a
> > special sched_switch_deadline tracepoint, that would record the existing
> > runtime,deadline and period for deadline tasks. It wont add more
> > tracepoints into the core scheduler, but use the existing one.  
> 
> You can display the joined version of sched deadline
> (yield|throttle|block) tracepoint, but IMHO this will just turn things
> more complex than they need to be, and will possibly add overhead to the
> sched_switch tracepoint, that is more used by non-deadline users than by
> deadline users.

Adding to the sched_switch tracepoint isn't as big of a deal as slowing
non tracing down. All new overhead must be focused into the tracing
enabled case. That is, if we slow down tracing by 100% where we could
have an alternative that slows down non-tracing by .01%, we still
choose the slowdown of tracing.

> 
> Moreover, deadline users will probably want to see only the deadline
> data, and have to use complex enabling/filtering options is really
> really not intuitive for users (that are not kernel developers).

That's what userspace filtering tools are for ;-)


-- Steve