linux-kernel - RE: sched/fair: scheduler not running high priority process on idle cpu

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:   Wed, 15 Jan 2020 12:57:10 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Steven Rostedt' <rostedt@...dmis.org>
CC:     'Vincent Guittot' <vincent.guittot@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: sched/fair: scheduler not running high priority process on idle
 cpu


From: Steven Rostedt
> Sent: 14 January 2020 17:48
...
> > The cost of ftrace function call entry/exit (about 200 clocks) makes it
> > rather unsuitable for any performance measurements unless only
> > a very few functions are traced - which rather requires you know
> > what the code is doing :-(
> >
> 
> Well, when I use function tracing, I start all of them, analyze the
> trace, then the functions I don't care about (usually spin locks and
> other utils), I add to the set_ftrace_notrace file,  which keeps them
> from being part of the trace. I keep doing this until I find a set of
> functions that doesn't hurt overhead as much and gives me enough
> information to know what is happening. It also helps to enable all or
> most events (at least scheduling events).

I've been using schedviz - but have had to 'fixup' wrapped traces so that
all the cpu traces start at the same time to get it to load them.
I managed to find what the worker thread was running - but only
because it ran for the entire time 'echo t >/proc/sysrq-trigger' took
to finish. Then I looked at the sources to find the code...

I'm surprised the 'normal case' for tracing function entry isn't done
in assembler without saving all the registers (etc).
For tsc stamps I think it should be possible saving just 3 registers
in under 32 instructions. Scaling to ns is a bit harder.
It's a shame the ns scaling isn't left to the reading code.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)