linux-kernel - Re: [RFC PATCH v3 2/2] tracing: add policy-based sched

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] [day] [month] [year] [list]

Message-ID: <20170207122356.GQ6515@twins.programming.kicks-ass.net>
Date:   Tue, 7 Feb 2017 13:23:56 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Julien Desfossez <jdesfossez@...icios.com>
Cc:     rostedt@...dmis.org, tglx@...utronix.de, mingo@...hat.com,
        bristot@...hat.com, mathieu.desnoyers@...icios.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3 2/2] tracing: add policy-based sched_switch events

On Fri, Jan 13, 2017 at 12:19:53PM -0500, Julien Desfossez wrote:
> Add 3 new tracepoints: sched_switch_fair, sched_switch_rt and
> sched_switch_dl.

Do they really _have_ to be whole new tracepoints? I really don't like
littering the user interface with all that.

Furthermore, it doesn't seem to make sense to enable these individually,
either all or none.

> These conditional tracepoints are emitted based on the scheduling class
> of the next task. Each of these tracepoint gets rid of the prio field
> from the original sched_switch and replaces it with fields that are
> relevant to the policy of the next task:
>   - for a fair task: the nice value,
>   - for a rt task: the nice and rt_priority values,

Nice is not relevant to RT.

>   - for a dl task: the runtime, deadline and period values.
> 
> The original sched_switch event is left unmodified, so these new events
> can be enabled at the same time (but they are emitted consecutively so
> we can see a timestamp offset).

So ideally there would only be _1_ sched_switch event that I can enable,
and it would (per default) not print the old style at all.

Some (global?) compat knob could be used to switch back to the old style
output with clear notification that that is going to go away 'soon'.