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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z01Vn8yZv-AlB-Z4@kernel.org>
Date: Mon, 2 Dec 2024 08:37:19 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ftrace: Show timings of how long nop patching took

On Sun, Dec 01, 2024 at 03:04:06PM -0500, Steven Rostedt wrote:
> On Sun, 1 Dec 2024 20:37:42 +0100
> Christophe Leroy <christophe.leroy@...roup.eu> wrote:
> 
> > Hi Steven,
> > 
> > Le 17/10/2024 à 17:31, Steven Rostedt a écrit :
> > > From: Steven Rostedt <rostedt@...dmis.org>
> > > 
> > > Since the beginning of ftrace, the code that did the patching had its
> > > timings saved on how long it took to complete. But this information was
> > > never exposed. It was used for debugging and exposing it was always
> > > something that was on the TODO list. Now it's time to expose it. There's
> > > even a file that is where it should go!
> > > 
> > > Also include how long patching modules took as a separate value.
> > > 
> > >   # cat /sys/kernel/tracing/dyn_ftrace_total_info
> > >   57680 pages:231 groups: 9
> > >   ftrace boot update time = 14024666 (ns)
> > >   ftrace module total update time = 126070 (ns)  
> > 
> > What is this supposed to report / measure ?
> > 
> > On powerpc I get:
> > 
> > 25850 pages:14 groups: 3
> > ftrace boot update time = 0 (ns)
> > ftrace module total update time = 0 (ns)
> 
> Hmm, does powerpc support "trace_clock_local()" at early boot? I
> probably can just switch from using "ftrace_now()" to using
> ktime_get_real_ts64(). Hmm.

The calls to timekeeping_init() and time_init() are after ftrace_init() so
unless an architecture sets up some clock in setup_arch() like x86 does
there won't be a clock to use.
 
> -- Steve

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ