From: Andi Kleen <andi@firstfloor.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Andi Kleen <andi@firstfloor.org>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Olsa <jolsa@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Jan Stancek <jstancek@redhat.com>
Subject: Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!
Date: Mon, 28 Nov 2016 15:10:34 -0800 [thread overview]
Message-ID: <20161128231034.GK26852@two.firstfloor.org> (raw)
In-Reply-To: <20161128174601.533d1f09@gandalf.local.home>
> Well, actually it's been optimized a lot from the first instances.
> Note, tracepoints need to be quite generic, so where it can be optimized
> is not obvious.
There is quite a bit of stuff that doesn't change from trace point to
trace point. So you could just cache all these decisions into a single
per cpu variable, and invalidate if anything changes the conditions.
> >
> > Functions with # of instructions:
> >
> > 25 trace_event_raw_event_sched_switch
>
> This is from the TRACE_EVENT macro.
>
> if (trace_trigger_soft_disabled(trace_file)) \
> return; \
Cache?
> if ((trace_file->flags & EVENT_FILE_FL_PID_FILTER) &&
> trace_event_ignore_this_pid(trace_file))
> return NULL;
>
> *current_rb = trace_file->tr->trace_buffer.buffer;
Indirection could be cached.
>
> if ((trace_file->flags &
> (EVENT_FILE_FL_SOFT_DISABLED | EVENT_FILE_FL_FILTERED)) &&
> (entry = this_cpu_read(trace_buffered_event))) {
Multiple tests of trace_file->flags in different functions,
could be all folded into a single test.
>
>
> Note: Some of these if statements can be encapsulated with jump labels, as they
> are false pretty much all of the time.
>
>
> /* Try to use the per cpu buffer first */
> val = this_cpu_inc_return(trace_buffered_event_cnt);
> if (val == 1) {
> trace_event_setup(entry, type, flags, pc);
> entry->array[0] = len;
> return entry;
> }
> this_cpu_dec(trace_buffered_event_cnt);
This can be pre cached in a fast path. If true just point per cpu
variable directly to buffer and invalidate if buffer changes or is full.
> preempt_disable_notrace();
>
> if (unlikely(atomic_read(&buffer->record_disabled)))
> goto out;
Cache.
>
> cpu = raw_smp_processor_id();
>
> if (unlikely(!cpumask_test_cpu(cpu, buffer->cpumask)))
> goto out;
Not needed for per cpu buffers in a fast path.
>
> cpu_buffer = buffer->buffers[cpu];
>
> if (unlikely(atomic_read(&cpu_buffer->record_disabled)))
> goto out;
cache
>
> if (unlikely(length > BUF_MAX_DATA_SIZE))
> goto out;
>
> if (unlikely(trace_recursive_lock(cpu_buffer)))
> goto out;
locking should invalidate state on this cpu, so shouldn't be needed
> u64 diff;
>
> rb_start_commit(cpu_buffer);
>
> #ifdef CONFIG_RING_BUFFER_ALLOW_SWAP
> /*
> * Due to the ability to swap a cpu buffer from a buffer
> * it is possible it was swapped before we committed.
> * (committing stops a swap). We check for it here and
> * if it happened, we have to fail the write.
> */
> barrier();
> if (unlikely(ACCESS_ONCE(cpu_buffer->buffer) != buffer)) {
> local_dec(&cpu_buffer->committing);
> local_dec(&cpu_buffer->commits);
> return NULL;
> }
swapping should invalidate state centrally (and then run slow path like
current path)
> /*
> * We allow for interrupts to reenter here and do a trace.
> * If one does, it will cause this original code to loop
> * back here. Even with heavy interrupts happening, this
> * should only happen a few times in a row. If this happens
> * 1000 times in a row, there must be either an interrupt
> * storm or we have something buggy.
> * Bail!
> */
> if (RB_WARN_ON(cpu_buffer, ++nr_loops > 1000))
> goto out_fail;
didn't you disable interrupts earlier?
> /* Did the write stamp get updated already? */
> if (likely(info.ts >= cpu_buffer->write_stamp)) {
> info.delta = diff;
> if (unlikely(test_time_stamp(info.delta)))
> rb_handle_timestamp(cpu_buffer, &info);
> }
Not sure why a write stamp is needed. isn't that the last few entries?
...
-Andi
next prev parent reply other threads:[~2016-11-28 23:10 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 0:53 [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage! Jiri Olsa
2016-11-21 9:02 ` Paul E. McKenney
2016-11-21 9:43 ` Peter Zijlstra
2016-11-21 11:00 ` Paul E. McKenney
2016-11-21 9:28 ` Peter Zijlstra
2016-11-21 9:34 ` Jiri Olsa
2016-11-21 9:42 ` Peter Zijlstra
2016-11-21 11:22 ` Jiri Olsa
2016-11-21 11:31 ` Peter Zijlstra
2016-11-21 12:49 ` Jiri Olsa
2016-11-21 12:58 ` Peter Zijlstra
2016-11-21 14:15 ` Steven Rostedt
2016-11-21 14:37 ` Peter Zijlstra
2016-11-21 15:35 ` Borislav Petkov
2016-11-21 15:41 ` Peter Zijlstra
2016-11-21 16:06 ` Borislav Petkov
2016-11-29 13:16 ` Borislav Petkov
2016-11-29 13:59 ` Thomas Gleixner
2016-11-30 8:48 ` Borislav Petkov
2016-11-30 8:54 ` Thomas Gleixner
2016-11-30 9:07 ` Borislav Petkov
2016-11-30 9:14 ` Thomas Gleixner
2016-11-29 14:04 ` Jiri Olsa
2016-11-21 14:20 ` Steven Rostedt
2016-11-21 17:06 ` Andi Kleen
2016-11-21 17:18 ` Peter Zijlstra
2016-11-21 17:45 ` Andi Kleen
2016-11-21 18:01 ` Steven Rostedt
2016-11-21 18:06 ` Andi Kleen
2016-11-21 18:22 ` Steven Rostedt
2016-11-21 18:37 ` Andi Kleen
2016-11-21 19:06 ` Steven Rostedt
2016-11-21 19:15 ` Steven Rostedt
2016-11-21 20:44 ` Andi Kleen
2016-11-22 8:19 ` Paul E. McKenney
2016-11-22 14:39 ` Steven Rostedt
2016-11-22 19:05 ` Andi Kleen
2016-11-24 2:06 ` Steven Rostedt
2016-11-28 21:48 ` Andi Kleen
2016-11-28 22:46 ` Steven Rostedt
2016-11-28 23:10 ` Andi Kleen [this message]
2016-11-21 17:55 ` Steven Rostedt
2016-11-21 18:24 ` Steven Rostedt
2016-11-21 20:12 ` Paul E. McKenney
2017-02-23 12:24 ` Jiri Olsa
2017-02-23 17:11 ` Andi Kleen
2017-02-23 17:28 ` Peter Zijlstra
2017-02-23 17:56 ` Borislav Petkov
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=20161128231034.GK26852@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=jolsa@redhat.com \
--cc=josh@joshtriplett.org \
--cc=jstancek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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