From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Nadav Amit <nadav.amit@gmail.com>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Song Liu <songliubraving@fb.com>,
Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH 3/3] x86/ftrace: Use text_poke()
Date: Thu, 3 Oct 2019 18:10:45 -0400 [thread overview]
Message-ID: <20191003181045.7fb1a5b3@gandalf.local.home> (raw)
In-Reply-To: <20191002182106.GC4643@worktop.programming.kicks-ass.net>
On Wed, 2 Oct 2019 20:21:06 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Oct 02, 2019 at 06:35:26PM +0200, Daniel Bristot de Oliveira wrote:
>
> > ftrace was already batching the updates, for instance, causing 3 IPIs to enable
> > all functions. The text_poke() batching also works. But because of the limited
> > buffer [ see the reply to the patch 2/3 ], it is flushing the buffer during the
> > operation, causing more IPIs than the previous code. Using the 5.4-rc1 in a VM,
> > when enabling the function tracer, I see 250+ intermediate text_poke_finish()
> > because of a full buffer...
> >
> > Would this be the case of trying to use a dynamically allocated buffer?
> >
> > Thoughts?
>
> Is it a problem? I tried growing the buffer (IIRC I made it 10 times
> bigger) and didn't see any performance improvements because of it.
I'm just worried if people are going to complain about the IPI burst.
Although, I just tried it out before applying this patch, and there's
still a bit of a burst. Not sure why. I did:
# cat /proc/interrupts > /tmp/before; echo function > /debug/tracing/current_tracer; cat /proc/interrupts > /tmp/after
# cat /proc/interrupts > /tmp/before1; echo nop > /debug/tracing/current_tracer; cat /proc/interrupts > /tmp/after1
Before this patch:
# diff /tmp/before /tmp/after
< CAL: 2342 2347 2116 2175 2446 2030 2416 2222 Function call interrupts
---
> CAL: 2462 2467 2236 2295 2446 2150 2536 2342 Function call interrupts
(Just showing the function call interrupts)
There appears to be 120 IPIs sent to all CPUS for enabling function tracer.
# diff /tmp/before1 /tmp/after1
< CAL: 2462 2467 2236 2295 2446 2150 2536 2342 Function call interrupts
---
> CAL: 2577 2582 2351 2410 2446 2265 2651 2457 Function call interrupts
And 151 IPIs for disabling it.
After applying this patch:
# diff /tmp/before /tmp/after
< CAL: 66070 46620 59955 59236 68707 63397 61644 62742 Function call interrupts
---
> CAL: 66727 47277 59955 59893 69364 64054 62301 63399 Function call interrupts
# diff /tmp/before1 /tmp/after1
< CAL: 66727 47277 59955 59893 69364 64054 62301 63399 Function call interrupts
---
> CAL: 67358 47938 59985 60554 70025 64715 62962 64060 Function call interrupts
We get 657 IPIs for enabling function tracer, and 661 for disabling it.
Funny how it's more on the disable than the enable with the patch but
the other way without it.
But still, we are going from 120 to 660 IPIs for every CPU. Not saying
it's a problem, but something that we should note. Someone (those that
don't like kernel interference) may complain.
-- Steve
next prev parent reply other threads:[~2019-10-03 22:10 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 18:06 [PATCH 0/3] Rewrite x86/ftrace to use text_poke() Peter Zijlstra
2019-08-27 18:06 ` [PATCH 1/3] x86/alternatives: Teach text_poke_bp() to emulate instructions Peter Zijlstra
2019-10-03 5:00 ` Masami Hiramatsu
2019-10-03 8:27 ` Peter Zijlstra
2019-10-03 11:01 ` Peter Zijlstra
2019-10-03 12:32 ` Peter Zijlstra
2019-10-04 13:45 ` Masami Hiramatsu
2019-10-07 8:05 ` Peter Zijlstra
2019-10-09 13:07 ` x86/kprobes bug? (was: [PATCH 1/3] x86/alternatives: Teach text_poke_bp() to emulate instructions) Peter Zijlstra
2019-10-09 13:26 ` Peter Zijlstra
2019-10-09 13:28 ` Peter Zijlstra
2019-10-09 14:26 ` Mathieu Desnoyers
2019-10-17 19:59 ` Peter Zijlstra
2019-10-03 13:05 ` [PATCH 1/3] x86/alternatives: Teach text_poke_bp() to emulate instructions Peter Zijlstra
2019-08-27 18:06 ` [PATCH 2/3] x86/alternatives,jump_label: Provide better text_poke() batching interface Peter Zijlstra
2019-10-02 16:34 ` Daniel Bristot de Oliveira
2019-10-03 5:50 ` Masami Hiramatsu
2019-08-27 18:06 ` [PATCH 3/3] x86/ftrace: Use text_poke() Peter Zijlstra
2019-10-02 16:35 ` Daniel Bristot de Oliveira
2019-10-02 18:21 ` Peter Zijlstra
2019-10-03 22:10 ` Steven Rostedt [this message]
2019-10-04 8:10 ` Daniel Bristot de Oliveira
2019-10-04 13:40 ` Steven Rostedt
2019-10-04 14:44 ` Daniel Bristot de Oliveira
2019-10-04 15:13 ` Steven Rostedt
2019-10-07 8:08 ` Peter Zijlstra
2019-10-11 7:01 ` Peter Zijlstra
2019-10-11 7:37 ` Daniel Bristot de Oliveira
2019-10-11 10:57 ` Peter Zijlstra
2019-10-11 13:11 ` Steven Rostedt
2019-10-04 11:22 ` Peter Zijlstra
2019-10-04 13:42 ` Steven Rostedt
2019-10-22 0:36 ` Alexei Starovoitov
2019-10-22 0:43 ` Steven Rostedt
2019-10-22 3:10 ` Alexei Starovoitov
2019-10-22 3:16 ` Steven Rostedt
2019-10-22 3:19 ` Steven Rostedt
2019-10-22 4:05 ` Alexei Starovoitov
2019-10-22 11:19 ` Steven Rostedt
2019-10-22 13:44 ` Steven Rostedt
2019-10-22 17:50 ` Alexei Starovoitov
2019-10-22 18:10 ` Steven Rostedt
2019-10-22 20:46 ` Alexei Starovoitov
2019-10-22 21:04 ` Steven Rostedt
2019-10-22 21:58 ` Alexei Starovoitov
2019-10-22 22:17 ` Steven Rostedt
2019-10-23 2:02 ` Steven Rostedt
2019-10-22 22:45 ` Andy Lutomirski
2019-10-22 23:21 ` Steven Rostedt
2019-10-22 23:49 ` Alexei Starovoitov
2019-10-23 4:20 ` Andy Lutomirski
2019-10-23 9:02 ` Peter Zijlstra
2019-10-23 16:23 ` Steven Rostedt
2019-10-23 17:42 ` Steven Rostedt
2019-10-23 19:34 ` Alexei Starovoitov
2019-10-23 20:08 ` Steven Rostedt
2019-10-23 22:36 ` Alexei Starovoitov
2019-10-22 3:55 ` Alexei Starovoitov
2019-10-03 5:52 ` Masami Hiramatsu
2019-08-28 7:22 ` [PATCH 0/3] Rewrite x86/ftrace to use text_poke() Song Liu
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=20191003181045.7fb1a5b3@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=bristot@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mhiramat@kernel.org \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.