linux-kernel - Re: [PATCH] sched/tracing: Reset critical timings on scheduling

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: <20210127111547.5c33f1c5@gandalf.local.home>
Date:   Wed, 27 Jan 2021 11:15:47 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Viktor Rosendahl <Viktor.Rosendahl@....de>
Subject: Re: [PATCH] sched/tracing: Reset critical timings on scheduling

On Wed, 27 Jan 2021 12:37:16 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> And that's just really daft.. why are you adding two unconditional
> function calls to __schedule() that are a complete waste of time
> 99.999999% of the time?
> 
> If anything, this should be fixed in schedule_idle().

Note, those two unconditional calls are only called when you have the
preempt or irqs off latency tracers enabled (which causes overhead on every
preempt_enable/disable and irqs enabled/disabled as well, and why we tell
people not to compile them in if you care about performance).

When irqs and preempt latency tracers are not enabled, we have this:

# define stop_critical_timings() do { } while (0)
# define start_critical_timings() do { } while (0)

static inline void reset_critical_timings(void) {
	stop_critical_timings();
	start_critical_timings();
}

which is basically a nop.

If you still care about the overhead to schedule when these tracers are
enabled (which is not much considered the overhead they cause elsewhere), we
can make it more specific to cpu idle.

I was worried that this could happen more than just in cpu idle, and added
it to the scheduler directly to make sure I got any other case.

-- Steve