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 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.