The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Steven Rostedt <rostedt@goodmis.org>, Mike Rapoport <rppt@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ftrace: Show timings of how long nop patching took
Date: Tue, 3 Dec 2024 08:21:49 +0100	[thread overview]
Message-ID: <37824159-8f7b-49ca-80d7-99c6d76e3f9a@csgroup.eu> (raw)
In-Reply-To: <20241202150516.3cf52584@gandalf.local.home>



Le 02/12/2024 à 21:05, Steven Rostedt a écrit :
> On Mon, 2 Dec 2024 08:37:19 +0200
> Mike Rapoport <rppt@kernel.org> wrote:
> 
>>>> 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.
> 
> Hmm, maybe I should add:
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index be62f0ea1814..362a125d7bcc 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -8588,14 +8588,23 @@ tracing_read_dyn_info(struct file *filp, char __user *ubuf,
>   		return -ENOMEM;
>   
>   	r = scnprintf(buf, DYN_INFO_BUF_SIZE,
> -		      "%ld pages:%ld groups: %ld\n"
> -		      "ftrace boot update time = %llu (ns)\n"
> -		      "ftrace module total update time = %llu (ns)\n",
> +		      "%ld pages:%ld groups: %ld\n",
>   		      ftrace_update_tot_cnt,
>   		      ftrace_number_of_pages,
> -		      ftrace_number_of_groups,
> -		      ftrace_update_time,
> -		      ftrace_total_mod_time);
> +		      ftrace_number_of_groups);
> +
> +	if (ftrace_update_time) {
> +		r += scnprintf(buf + r, DYN_INFO_BUF_SIZE - r,
> +			       "ftrace boot update time = %llu (ns)\n",
> +			       ftrace_update_time);
> +	} else {
> +		r += scnprintf(buf + r, DYN_INFO_BUF_SIZE - r,
> +			       "ftrace boot update time = [Unavailable]\n");
> +	}
> +
> +	r += scnprintf(buf + r, DYN_INFO_BUF_SIZE - r,
> +		       "ftrace module total update time = %llu (ns)\n",
> +		       ftrace_total_mod_time);
>   
>   	ret = simple_read_from_buffer(ubuf, cnt, ppos, buf, r);
>   	kfree(buf);
> 
> Which should turn the above to:
> 
>    25850 pages:14 groups: 3
>    ftrace boot update time = [Unavailable]
>    ftrace module total update time = 0 (ns)
> 
> Which should at least make it not confusing.

Well. Maybe, but at the end what we need is the measured value, if it 
only works on x86 it is just pointless, isn't it ?

trace_clock_local() calls sched_clock()

I don't know about other architectures, but on powerpc sched_clock() is:

	notrace unsigned long long sched_clock(void)
	{
		return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
	}

boot_tb, tb_to_ns_scale and tb_to_ns_shift are not known before 
time_init() is called.

But get_tb() returns a valid value already so it is possible to get the 
ticks and do the calculation later with tb_to_ns()


> 
> I'm assuming that the module timings are zero because no modules were loaded?

Indeed I don't even have CONFIG_MODULES, maybe the complete line should 
be removed in that case.

Christophe

  reply	other threads:[~2024-12-03  7:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17 15:31 [PATCH] ftrace: Show timings of how long nop patching took Steven Rostedt
2024-12-01 19:37 ` Christophe Leroy
2024-12-01 20:04   ` Steven Rostedt
2024-12-02  6:37     ` Mike Rapoport
2024-12-02 20:05       ` Steven Rostedt
2024-12-03  7:21         ` Christophe Leroy [this message]
2024-12-03 15:17           ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37824159-8f7b-49ca-80d7-99c6d76e3f9a@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox